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Achieving  Net-Centric  Warfare  Capabilities 

For  U.S.  Forces  to  counter  current  and  future  threats  successfully,  they  must  operate  worldwide 
with  speed,  agility,  and  flexibility.  Key  to  achieving  this  required  level  of  responsiveness  is 
providing  the  quality,  shared  situation  awareness,  and  understanding  necessary  to  make  sound 
individual  and  collective  judgments.  This  goal,  in  turn,  requires  widespread  access  to  secure,  accurate, 
current,  and  timely  information  and  the  capability  to  share  this  information  securely  among  U.S., 
coalition  and  allied  forces,  as  well  as  with  non-military  and  non-governmental  organizations. 
Achieving  this  information  end-state  will  result  in  our  forces  attaining  Information  Superiority  over 
potential  adversaries. 

Information  Superiority,  as  stipulated  in  Joint  Vision  2020  (JV  2020),  will  be  achieved  by  robustly 
networking  our  Force  in  a  manner  that  allows  information  to  be  readily  shared  among  people,  sensors, 
and  weapon  platforms  throughout  the  battle  space,  as  well  as  between  the  communities  of  interest 
representing  enterprise  business  activities.  The  Global  Information  Grid  (GIG) — a  seamless, 
common-user,  information  infrastructure — will  be  the  foundation  for  Information  Superiority  by 
providing  the  enterprise-wide  information  services  for  the  Department  of  Defense’s  (DoD)  Command, 
Control,  Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  and 
e-Business  systems. 

Integration  of  these  systems  into  the  GIG  will  require  that  they  adhere  to  open  standards  that  facilitate 
their  interoperability.  Transformation  of  DoD’s  capabilities,  in  the  broadest  sense,  requires  that  existing 
systems  arc  transformed  in  such  a  manner  that  they  can  share  their  information  easily  and  promptly.  It 
also  requires  that  the  GIG  provide  the  services  that  allow  the  discovery  of  and  collaborative  use  of  this 
information  for  the  purpose  of  effective  and  efficient  business  or  battle-space  management. 

When  fully  transformed,  the  GIG  will  be  a  key  element  of  future  combat  power.  It  will  move  the  DoD 
beyond  traditional  communities  of  interest  (i.e.,  command  and  control,  intelligence,  and  logistics)  to  a 
net-centric,  globally  focused  information  environment.  Maximizing  the  use  of  commercial 
technologies  and  standards,  the  GIG  will  consist  of  a  tiered  transport  layer  and  a  Network  Centric 
Enterprise  Services  (NCES)  layer  that  fully  support  the  information  needs  of  our  warfighters  and  the 
DoD  enterprise.  Information  assurance  will  be  integral  to  the  GIG,  and  data  management  strategy 
initiatives  will  ensure  that  data  is  appropriately  tagged,  posted,  and  made  available  to  others  with 
access  to  the  “net.” 

Changes  Supporting  the  DoD’s  Transformation  Objectives 

To  support  the  DoD’s  transformation  objectives,  several  key  information  technology  (IT)  processes, 
programs,  and  related  documents  have  been  recently  updated.  The  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  (CJCSI  3170.01C  and  CJCSM  3170.01)  restructured  the  requirements 
process  used  to  assess  existing  and  proposed  capabilities  with  respect  to  future  Joint  Operational 
Concepts  (JOCs),  Joint  Functional  Concepts  (JFCs),  and  Mission  Area  Integrated  Architecture.  The 
JCIDS  was  developed  in  coordination  with  the  release  of  the  new  DoD  5000  (DoDI  5000.2)  Defense 
Acquisition  System  series  to  ensure  integration  of  the  capabilities  development  and  acquisition 
processes  through  the  use  of  integrated  architectures,  including  the  GIG  integrated  architecture. 

In  addition,  DoD  Directive  (DoDD)  8000. 1  defines  policies  and  responsibilities  for  information 
resource  and  technology  management.  This  directive  establishes  the  DoD  Chief  Information  Officer 
(CIO)  as  the  entity  responsible  for  enterprise  architecture,  IT  investment  strategy,  and  integration 
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oversight.  DoDD  8100.1  establishes  the  GIG  as  the  DoD’s  enterprise  level  architecture  for  net-centric 
operations  and  warfare  and  also  establishes  responsibilities  for  the  acquisition  and  operation  of  GIG 
assets.  DoDD  4630.5  and  DoDI  4630.8  establish  the  responsibilities  of  the  CIO  and  other  components 
for  information  interoperability. 

These  directives  reference  the  use  of  an  integrated  set  of  DoD  enterprise  architectures.  Integrated 
architectures  describe  relationships  between  tasks  and  activities  that  generate  effects  on  enemy  forces 
and  their  supporting  operations.  The  directives  specify  that  integrated  architectures  must  have  three 
views:  operational,  systems,  and  technical,  as  defined  in  the  Architecture  Framework.  The  standards 
comprising  the  Technical  View  in  an  integrated  architecture  must  be  selected  from  those  contained  in 
the  currently  approved  version  of  the  JTA. 

In  accordance  with  DoDI  5000.2  and  DoDI  4630.8,  compliance  with  the  JTA — having  a  Technical 
View  derived  from  the  standards  and  guidelines  contained  therein — is  required  at  all  program  milestone 
decisions.  The  Overarching  Integrated  Product  Team  (OIPT)  will  include,  as  paid  of  the  review  process, 
an  assessment  of  JTA  compliance  in  the  program’s  development,  design,  implementation,  and  test 
activities.  CJCSI  6212.01C  defines  the  Net-Ready  Key  Performance  Parameter  (KPP)  which  is  based 
on  the  use  of  the  GIG  Integrated  Architecture.  The  Net-Ready  KPP  will  be  used  to  assess  net  readiness, 
information  assurance  requirements,  and  both  the  technical  exchange  of  information  and  the  end-to-end 
operational  effectiveness  of  that  exchange.  The  Net-Ready  KPP  requires  that  the  Technical  Views 
(TV-1)  arc  based  on  the  JTA.  Compliance  with  the  JTA  will  be  a  requirement  for  a  program  to  move 
forward  in  the  acquisition  processes,  unless  a  waiver  approving  noncompliance  is  obtained  in 
accordance  with  the  JTA  governance  policy  to  be  issued  by  the  DoD’s  CIO. 

Refocusing  the  JTA  on  Transformation 

The  JTA  defines  the  service  areas,  interfaces,  and  standards  applicable  to  all  DoD  systems;  its  use  is 
mandatory  for  the  management,  development,  and  acquisition  of  new  or  improved  systems  throughout 
the  DoD.  Version  5.x  and  earlier  of  the  JTA  were  broadly  inclusive  of  commercial  and  military  IT 
standards  that  reflected  the  business  and  national  security  related  systems  that  either  existed  in  the  past 
or  would  be  procured  in  the  future.  Version  6.0  and  future  versions  of  the  JTA  will  focus  on 
transforming  the  DoD’s  existing  IT  infrastructure  and  systems  in  order  to  achieve  its  net-centric  vision. 
Using  the  JTA,  systems — e-Business  or  National  Security  Systems  (NSS),  including  weapons 
systems — will  become  integral  parts  of  the  GIG. 

Refocusing  the  JTA  resulted  in  the  removal  of  standards  that  did  not  support  the  DoD’s  goal  for 
transforming  to  the  GIG  or  the  DoD  Net-Centric  Data  Strategy  (May  9,  2003).  In  addition,  numerous 
standards  have  been  marked  sunset,  indicating  deletion  from  the  JTA  on  a  future  date  to  be  determined 
by  a  specific,  predefined  programmatic  event.  The  standards  and  guidelines  listed  in  Volume  I  of  the 
JTA  are  stable,  technically  mature,  and  publicly  available  (and  primarily  commercial -IT  based),  and 
they  support  the  net-centric  vision  of  the  GIG.  Emerging  standards  arc  maintained  in  a  separate  volume 
of  the  JTA  as  described  below. 

Intended  Use  of  the  JTA 

The  JTA  delineates  mandatory  standards  and  guidelines  in  Volume  I.  In  addition,  selected  services  and 
functions  are  identified  with  a  sunset  clause  and,  thus,  will  be  removed  as  indicated  above.  The 
continued  use  of  sunset  standards  is  discouraged.  Volume  II  of  the  JTA  Version  6.0  lists  emerging, 
net-centric  standards  and  guidelines  to  be  used  as  reference  material  for  the  acquisition  community,  but 
they  should  not  be  adhered  to  until  they  become  mandatory  in  future  versions  of  the  JTA. 
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Volume  I:  Mandatory  Standards  and  Guidelines 

Volume  I  consists  of  two  main  parts:  1)  core  standards  characterized  as  those  applicable  to  all  DoD 
systems  and  2)  domain-specific  standards  (applicable  to  specific  functional  domains  or  families  of 
systems).  The  current  version  of  the  JTA  includes  domains  for  C4ISR,  Combat  Support,  Modeling  and 
Simulation,  and  Weapon  Systems.  Where  subsets  of  an  application  domain  have  special  requirements, 
the  JTA  includes  subdomains  containing  standards  and  guidelines  applicable  to  systems  within  that 
subdomain.  This  document  intends  that  a  system  within  a  specific  subdomain  adopts  the  JTA  elements 
contained  in  the  relevant  subdomain,  the  JTA  elements  contained  in  the  parent  domain,  and  the  JTA 
elements  contained  in  the  JTA  Core. 

All  DoD  systems  that  employ  services  and  functions  identified  and  defined  in  Volume  I  must  use 
related  mandatory  standards  and  guidelines  in  that  volume.  In  addition,  all  e-Business  or  National 
Security  systems  acquired  on  or  after  October  2003  must  adhere  to  these  standards  and  guidelines.  All 
DoD  systems  employing  those  services  and  functions  in  Volume  I  that  have  sunset  clauses  must  provide 
transition  plans  explaining  how  the  systems  will  transition  from  those  standards  to  the  ones  that  will 
replace  them  when  they  arc  removed  from  the  JTA.  These  plans  will  be  received  as  paid  of  the  milestone 
acquisition  process  associated  with  the  respective  program. 

The  selection  of  the  mandatory  standards  and  guidelines  in  the  JTA  is  based  upon  achieving 
interoperability  in  a  net-centric  enterprise.  Therefore,  only  a  minimum  set  of  essential  standards  is 
included.  The  standards  selected  arc  essential  for  providing  interoperability  and  net-centric  services 
across  the  DoD  enterprise  and  are  consistent  with  the  GIG  architecture.  These  standards  do  not  include 
vendor-unique  standards. 

Legacy  systems  using  deleted  standards  from  earlier  versions  of  the  JTA  arc  not  intended  to  upgrade  in 
order  to  adhere  to  the  mandatory  standards.  It  is  anticipated  that  these  systems  will  eventually  be  phased 
out  as  the  DoD  shifts  its  IT  infrastructure  toward  the  network-based  services  framework.  However,  if 
the  system  in  question  remains  a  critical  capability,  a  transition  plan  will  be  required  to  illustrate  the 
system’s  transition  into  the  GIG. 

Facilitating  Interoperability  in  DoD  Systems 

The  JTA  is  complementary  to,  and  consistent  with,  other  DoD  programs  and  initiatives  aimed  at 
the  development  and  acquisition  of  effective,  interoperable  systems.  These  include,  for  example,  the 
DoD’s  Specification  and  Standards  Reform,  the  implementation  of  the  Information  Technology 
Management  Reform  Act  (ITMRA),  the  Defense  Modeling  and  Simulation  Initiative,  and  the 
Open  Systems  Initiative. 

Maintenance  of  the  JTA  is  conducted  by  the  JTA  Development  Group  (JTADG),  directed  by  the 
Technical  Architecture  Steering  Group  (TASG),  and  approved  by  the  DoD  CIO.  Members  involved  in 
the  effort  represent  the  DoD  Components — Office  of  the  Secretary  of  Defense  (OSD),  the  Military 
Services,  the  Office  of  the  Joint  Chiefs  of  Staff  (OJCS),  the  Unified  and  Specified  Combatant 
Commands,  the  Defense  Agencies,  and  components  of  the  Intelligence  Community.  However,  by  the 
statutory  authority  vested  in  the  DoD  CIO,  this  entity  will  have  the  final  decision-making  authority  to 
determine  which  standards  are  mandatory,  sunset,  or  removed  from  future  versions  of  the  JTA.  It  will 
be  the  goal  of  the  CIO,  working  in  collaboration  with  the  Services,  Agencies,  and  components  of  the 
DoD  and  with  the  Intelligence  Community,  that  the  JTA  remain  a  minimal  set  of  primarily 
commercial-based  standards  that  will  guide  the  evolution  of  the  GIG  toward  becoming  an 
enterprise-wide  infrastructure  supporting  all  DoD  activities  from  national  security  to  e-Business. 
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The  JTA  is  an  evolving  knowledge  base  and  will  keep  pace  with  the  technologies,  marketplace,  and  the 
associated  standards  upon  which  it  is  based. 
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Section  1 :  Overview  of  the  Department  of  Defense 
Joint  Technical  Architecture 


1.1  Introduction 

Warfighter  battlespace  is  complex  and  dynamic,  requiring  timely  and  informed  decisions  by  all  levels 
of  military  command.  There  is  an  unprecedented  increase  in  the  amount  of  data  and  information 
necessary  to  conduct  operational  planning  and  combat  decision-making.  Information  concerning 
targets,  movement  of  forces,  condition  of  equipment,  levels  of  supplies,  and  disposition  of  assets — both 
friendly  and  unfriendly — must  be  provided  to  joint  commanders  and  their  forces.  Therefore, 
information  must  flow  quickly  and  seamlessly  among  all  tactical,  strategic,  and  supporting  elements. 

Warfighters  must  be  able  to  work  together  within  and  across  services  in  ways  not  totally  defined  in 
today’s  operational  concepts  and/or  architectures.  Warfighters  must  be  able  to  obtain  and  use 
intelligence  from  national  and  theater  assets  that  may  be  widely  dispersed  geographically.  Today’s 
split-base/reach-back  concept  requires  them  to  obtain  their  logistics  and  administrative  support  from 
both  home  bases  and  deployed  locations.  This  requires  that  information  flow  quickly  and  seamlessly 
among  the  Department  of  Defense  (DoD)  sensors,  processing  and  command  centers,  shooters,  and 
support  activities  to  achieve  dominant  battlefield  awareness  and  move  inside  the  enemy’s  decision 
loop. 

The  DoD  Joint  Technical  Architecture  (JTA)  provides  the  minimum  set  of  essential  standards  that, 
when  implemented,  facilitates  this  flow  of  information  in  support  of  the  warfighter.  The  JTA  standards 
promote: 

□  A  distributed  information  processing  environment  in  which  applications  are  integrated. 

□  Applications  and  data  independent  of  hardware  to  achieve  true  integration. 

□  Information  transfer  capabilities  to  ensure  seamless  communications  within  and  across  diverse 
media. 

□  Information  in  a  common  format  with  a  common  meaning. 

□  Common  human-computer  interfaces  for  users. 

□  Effective  means  to  protect  the  information. 

The  JTA  defines  the  service  areas,  interfaces,  and  standards  applicable  to  all  DoD  systems;  its  use  is 
mandatory  for  the  management,  development,  and  acquisition  of  new  or  improved  systems  throughout 
the  DoD. 

1.2  Purpose 

Section  1  provides  an  overview  of  the  JTA.  It  includes  the  JTA  purpose,  scope,  background,  and 
applicability;  introduces  basic  architecture  concepts;  and  discusses  the  selection  criteria  for  standards 
incorporated  in  the  document. 

Also  addressed  are  the  roles  of  the  DoD  Technical  Reference  Model  (TRM)  and  the  Combined 
Communications-Electronics  Board  (CCEB). 
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The  JTA  improves  and  facilitates  the  ability  of  our  systems  to  support  joint  and  combined  operations  in 
an  overall  investment  strategy. 

The  JTA: 

□  Provides  the  foundation  for  interoperability  among  all  tactical,  strategic,  and  combat  support 
systems  in  a  net-centric  enterprise. 

□  Mandates  IT  standards  and  guidelines  for  DoD  system  development  and  acquisition  that  will 
facilitate  interoperability  in  joint  and  coalition  force  operations.  These  standards  are  to  be 
applied  in  concert  with  DoD  standards  reform. 

□  Communicates  to  industry  DoD’s  preference  for  open  system,  standards-based  products,  and 
implementations. 

□  Acknowledges  the  direction  of  industry’s  standards-based  development. 

□  Facilitates  DoD’s  transformation  to  a  network  centric  operations  warfare  environment. 

1.3  Scope  (Applicability) 

The  JTA  is  considered  a  living  document  and  will  be  updated  periodically  as  a  collaborative  effort 
among  the  DoD  Components  (Commands,  Services,  and  Agencies)  to  leverage  technology 
advancements,  standards  maturity,  open  systems,  commercial-product  availability,  and  changing 
requirements. 

The  JTA  is  critical  to  achieving  the  envisioned  objective  of  a  cost-effective,  seamlessly  integrated 
environment.  Achieving  and  maintaining  this  vision  requires  interoperability: 

□  Within  a  Joint  Task  Force/Combatant  Command  Area  of  Responsibility  (AOR). 

□  Across  Combatant  Command  AOR  boundaries. 

□  Between  strategic  and  tactical  systems. 

□  Within  and  across  Services  and  Agencies. 

□  From  the  battlefield  to  the  sustaining  base. 

□  Among  U.S.,  Allied,  and  Coalition  forces. 

□  Across  current  and  future  systems. 

This  version  of  the  JTA  mandates  the  minimum  set  of  essential  standards  and  guidelines  for  the 
acquisition  of  all  DoD  systems  that  produce,  use,  or  exchange  information.  The  applicable  mandated 
standards  in  the  JTA  are  the  starting  set  of  standards  for  a  system,  and  additional  standards  may  be 
used  to  meet  requirements  if  they  are  not  in  conflict  with  standards  mandated  in  the  JTA.  The  JTA  is 
used  by  anyone  involved  in  the  acquisition,  development,  or  management  of  new  or  improved  systems 
within  the  DoD.  Specific  guidance  for  implementing  this  JTA  is  provided  in  the  separate  DoD 
Component  JTA  implementation  plans.  Operational  requirements  developers  are  cognizant  of  the  JTA 
in  developing  requirements  and  functional  descriptions.  System  developers  use  the  JTA  to  facilitate  the 
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achievement  of  interoperability  for  new  and  upgraded  systems  (and  the  interfaces  to  such  systems). 
System  integrators  use  it  to  foster  the  integration  of  existing  and  new  systems. 

1.4  Background 

The  evolution  of  a  national  military  strategy  in  the  post-Cold  War  era  and  the  lessons  learned  from 
conflicts  like  Desert  Shield/Desert  Storm  have  resulted  in  a  new  vision  for  DoD.  Joint  Vision  2010 
(JV  2010)  is  the  conceptual  template  for  how  America’s  Armed  Forces  will  channel  the  vitality  and 
innovation  of  their  people  and  leverage  technological  opportunities  to  achieve  new  levels  of 
effectiveness  in  joint  warfighting.  This  template  provides  a  common  direction  to  our  Services  in 
developing  their  unique  capabilities  within  a  joint  framework  of  doctrine  and  programs  as  they  prepare 
to  meet  an  uncertain  and  challenging  future.  The  Chairman  of  the  Joint  Chiefs  of  Staff  said  in  JV  2010, 
“The  nature  of  modern  warfare  demands  that  we  fight  as  a  joint  team.  This  was  important  yesterday,  it 
is  essential  today,  and  it  will  be  even  more  imperative  tomorrow.” 

JV  2010  creates  a  broad  framework  for  understanding  joint  warfare  in  the  future,  and  for  shaping 
Service  programs  and  capabilities  to  fill  our  role  within  that  framework.  JV  2010  defines  four 
operational  concepts:  Precision  Engagement,  Dominant  Maneuver,  Focused  Logistics,  and  Full 
Dimensional  Protection.  These  concepts  combine  to  ensure  that  American  forces  can  secure  Full 
Spectrum  Dominance  (i.e.,  the  capability  to  dominate  an  opponent  across  the  range  of  military 
operations  and  domains).  Furthermore,  Full  Spectrum  Dominance  requires  Information  Superiority 
(i.e.,  the  capability  to  collect,  process,  analyze,  and  disseminate  information  while  denying  an 
adversary  the  ability  to  do  the  same).  Interoperability  is  crucial  to  Information  Superiority. 

Recognizing  the  need  for  joint  operations  in  combat  and  the  reality  of  a  shrinking  budget,  the  Assistant 
Secretary  of  Defense  (Command,  Control,  Communications,  and  Intelligence)  (ASD[C3Ij)  issued  a 
memorandum  on  14  November  1995  to  Command,  Service,  and  Agency  principals  involved  in  the 
development  of  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  systems. 
This  directive  tasked  them  to  “reach  a  consensus  of  a  working  set  of  standards”  and  “establish  a  single, 
unifying  DoD  technical  architecture  (TA)  that  will  become  binding  on  all  future  DoD  C4I  acquisitions” 
so  that  “new  systems  can  be  born  joint  and  interoperable,  and  existing  systems  will  have  a  baseline  to 
move  toward  interoperability.” 

A  Joint  Technical  Architecture  Working  Group  (JTAWG)  chaired  by  ASD(C3I)  was  formed,  and  its 
members  agreed  to  use  the  U.S.  Army  Technical  Architecture  (ATA)  as  the  starting  point  for  the  JTA. 
JTA  Version  1.0  was  released  on  22  August  1996  and  was  immediately  mandated  by  the  Under 
Secretary  of  Defense,  Acquisition  and  Technology  (USD[A&Tj)  and  ASD(C3I)  for  all  new  and 
upgraded  C4I  systems  in  DoD. 

JTA  Version  2.0  development  began  in  March  1997  under  the  direction  of  a  Technical  Architecture 
Steering  Group  (TASG),  co-chaired  by  ASD(C3I)  and  USD(AT&L)  Open  Systems  Joint  Task  Force 
(OSJTF).  The  applicability  and  scope  of  JTA  Version  2.0  was  expanded  to  include  the  information 
technology  in  all  DoD  systems. 

JTA  Version  3.0  development  began  in  June  1998.  JTA  Version  3.0  includes  additional  subdomains  and 
incorporated  the  newly  developed  DoD  Technical  Reference  Model  (TRM).  JTA  Version  3. 1  mandated 
a  Gigabit  Ethernet  standard. 

JTAVersion  4.0  development  began  in  November  1999.  JTA  Version  4.0  removes  the  Orange  Book 
mandate  and  mandates  the  Common  Criteria. 
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JTA  Version  5.0  development  began  in  2001.  JTA  Version  5.0  eliminated  the  Nuclear  Command  and 
Control  Subdomain,  and  Linux  was  mandated  as  one  of  the  three  Operating  System  Services. 

JTA  Version  6.0  development  began  in  March  2003.  Volume  I  lists  the  mandated  standards  and 
guidelines;  Volume  II  lists  emerging  standards.  Version  6.0  and  future  versions  of  the  JTA  will  focus 
on  transforming  the  DoD’s  existing  IT  infrastructure  and  systems  in  order  to  achieve  its  net-centric 
vision.  Using  the  JTA,  systems  (e-Business  or  National  Security)  will  become  integral  parts  of  the  GIG. 

Refocusing  the  JTA  resulted  in  the  removal  of  numerous  standards  that  did  not  support  the  DoD’s  goal 
for  transforming  to  the  GIG  or  the  DoD  Net-Centric  Data  Strategy  (May  9,  2003).  In  addition, 
numerous  standards  have  been  marked  sunset,  indicating  deletion  from  the  JTA  on  a  future  date  to  be 
determined  by  a  specific,  predefined  programmatic  event.  The  standards  and  guidelines  listed  in  the 
JTA  are  stable,  technically  mature,  and  publicly  available  (and  primarily  commercial-IT  based),  and 
they  support  the  net-centric  vision  of  the  GIG. 

1.5  Architectures  Defined 

The  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance 
Domain  (C4ISR)  Architecture  Framework  (CAF)  provides  information  addressing  the  development 
and  presentation  of  architectures.  The  framework  provides  the  rules,  guidance,  and  product  descriptions 
for  developing  and  presenting  architectures  to  ensure  a  common  denominator  for  understanding, 
comparing,  and  integrating  architectures  across  and  within  the  DoD. 

An  architecture  is  defined  as  the  structure  of  components,  their  relationships,  and  the  principles  and 
guidelines  governing  their  design  and  evolution  over  time.  DoD  has  implemented  this  by  defining  an 
interrelated  set  of  views:  operational,  system,  and  technical.  Figure  1-1  shows  the  relationship  among 
the  three  views.  The  definitions  are  provided  here  to  ensure  a  common  understanding  of  the  three 
views.1 * 3 

1.5.1  Operational  Architecture  View 

The  Operational  Architecture  (OA)  view  describes  the  tasks  and  activities,  operational  elements,  and 
information  flows  required  to  accomplish  or  support  a  military  operation. 

It  contains  descriptions  (often  graphical)  of  the  operational  elements,  assigned  tasks  and  activities,  and 
the  information  flows  required  to  support  the  warfighter.  It  defines  the  types  of  information  exchanged, 
the  frequency  of  exchange,  which  tasks  and  activities  are  supported  by  the  information  exchanges,  and 
the  nature  of  information  exchanges  in  detail  sufficient  to  ascertain  specific  interoperability 
requirements. 

1.5.2  Technical  Architecture  View 

The  Technical  Architecture  (TA)  view  contains  the  minimal  set  of  rules  governing  the  arrangement, 
interaction,  and  interdependence  of  system  parts  or  elements,  whose  puipose  is  to  ensure  that  a 
conformant  system  satisfies  a  specified  set  of  requirements. 

The  TA  view  provides  the  technical  systems  implementation  guidelines  upon  which  engineering 
specifications  are  based,  common  building  blocks  are  established,  and  product  lines  are  developed.  The 
TA  view  includes  a  collection  of  the  technical  standards,  conventions,  rules,  and  criteria  organized  into 


1  These  definitions  are  extracted  from  the  C4ISR  Architecture  Framework  2.0.  The  definitions  and  the  products  required  by  the 
framework  focus  on  information  technology.  However,  the  concepts  described  can  be  applied  to  a  wide  range  of  technologies. 
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Figure  1-1 :  Architecture  Views  Relationships 


profile(s)  that  govern  system  services,  interfaces,  and  relationships  for  particular  systems-architecture 
views  and  that  relate  to  particular  operational  views. 

1 .5.3  Systems  Architecture  View 

The  Systems  Architecture  (SA)  view  is  a  description,  including  graphics,  of  systems  and 
interconnections  providing  for  or  supporting  warfighting  functions.  For  a  domain,  the  SA  view  shows 
how  multiple  systems  link  and  interoperate,  and  may  describe  the  internal  construction  and  operations 
of  particular  systems  within  the  architecture.  For  the  individual  system,  the  SA  view  includes  the 
physical  connection,  location,  and  identification  of  key  nodes  (including  materiel-item  nodes),  circuits, 
networks,  warfighting  platforms,  etc.,  and  it  specifies  system  and  component  performance  parameters 
(e.g.,  mean  time  between  failure,  maintainability,  and  availability).  The  SA  view  associates  physical 
resources  and  their  performance  attributes  to  the  OA  view  and  its  requirements  following  standards 
defined  in  the  TA. 

1.6  Relationships  between  the  C4ISR  Architecture  Framework  2.0  and  the  DoD  JTA 

The  C4ISR  Architecture  Framework  (CAF)  defines  the  TA  view  and  a  set  of  standard  technical 
products  for  DoD  use.  The  JTA  is  one  of  the  Universal  Reference  Resources  named  in  the  CAF.  The 
JTA  is  the  primary  source  document  to  the  essential  and  supporting  TA  products  defined  in  the  CAF. 
Standards  chosen  from  the  JTA  and  other  sources  to  meet  system  and  operational  requirements  are 
incorporated  into  the  TA  view. 

1.7  Document  Organization 

The  JTA  is  organized  into  two  volumes.  Volume  I  contains  mandated  standards;  Volume  II  contains 
emerging  standards.  Each  volume  includes  a  main  body,  followed  by  domains,  subdomains,  and  a  set 
of  appendices. 
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1.7.1  General  Volume  Organization 

The  main  body  of  each  volume  identifies  the  “Core”  set  of  JTA  elements  consisting  of  service  areas, 
interfaces,  and  standards.  The  JTA  Core  establishes  the  minimum  set  of  rules  governing  information 
technology  across  all  DoD  systems.  Additional  domain-specific  standards  are  found  in  the 
corresponding  domains  and  subdomains.  They  include  standards  for  information  processing, 
information  transfer,  the  structure  of  information  and  data,  human-computer  interface  for  information 
entry  and  display,  and  information  system  security.  Information  technology  (IT)  includes  any 
equipment  or  interconnected  system  or  subsystem  of  equipment  used  in  the  automatic  acquisition, 
storage,  manipulation,  management,  movement,  control,  display,  switching,  interchange,  transmission, 
or  reception  of  data  or  information.  Each  section  of  the  main  body,  except  for  the  overview,  is  divided 
into  four  subsections  as  follows: 

□  Introduction,  Purpose,  Scope,  and  Background:  These  subsections  are  for  information  puiposes 
only.  They  define  the  purpose  and  scope  of  the  document  and  the  section  and  provide 
background  descriptions  and  definitions  that  are  unique  to  this  section. 

□  Service  Area  and  Services:  This  subsection  describes  the  technical  overview  of  the  Services  in 
this  section. 

□  Mandated  Standards:  Volume  I  of  this  document  identifies  mandatory  standards  or  practices. 
Each  mandated  standard  or  practice  is  clearly  identified  on  a  separate  bulletized  (•)  line  and 
includes  a  formal  reference  citation  suitable  for  inclusion  within  a  Request  for  Proposals  (RFP), 
Statement  of  Work  (SOW),  or  Statement  of  Objectives  (SOO).  Selected  services  and  functions 
in  Volume  I  mandate  standards  and  guidelines  with  a  “[SUNSET]”  clause.  The  “[SUNSET]” 
clause  identifies  those  standards  or  guidelines  as  marked  for  removal  from  the  JTA  on  a  future 
date.  The  future  removal  of  those  marked  standards  and  guidelines  will  be  determined  by  a 
specific,  pre-defined  programmatic  event.  All  DoD  systems  employing  those  standards  in 
Volume  I  that  have  a  “[SUNSET]”  clause  must  provide  a  transition  plan  explaining  how  the 
system  will  transition  from  that  standard  when  it  is  removed  from  the  JTA. 

□  Emerging  Standards:  Volume  II  provides  an  information-only  description  of  standards  that  are 
candidates  for  possible  additions  to  the  JTA  mandated  standards.  Each  emerging  standard  is 
clearly  identified  on  a  separate  dashed  (-)  line.  The  purpose  of  listing  these  candidates  is  to  help 
the  program  manager  determine  those  areas  likely  to  change  within  three  years  and  to  suggest 
those  areas  in  which  “upgradability”  should  be  a  concern.  The  expectation  is  that  emerging 
standards  will  be  elevated  to  “mandatory”  status  when  implementations  of  the  standards 
mature.  Emerging  standards  may  be  implemented,  but  shall  not  be  used  in  lieu  of  a  mandated 
standard. 

1.7.2  Information  Technology  Standards 

The  JTA  Core,  or  the  main  body,  addresses  commercial  and  Government  standards  common  to  most 
DoD  information  technology  (IT),  grouped  into  categories  each  of  which  addresses  a  set  of  functions 
common  to  most  DoD  IT  systems.  The  IT  categories  are: 

□  Information  Processing  Standards:  Section  2  describes  Government  and  commercial 
information  processing  standards  DoD  uses  to  develop  integrated,  interoperable  systems  that 
meet  the  information  processing  requirements  of  warfighters. 
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□  Information  Transfer  Standards:  Section  3  describes  the  information  transfer  standards  and 
profiles  that  are  essential  for  information  transfer  interoperability  and  seamless 
communications.  This  section  mandates  the  use  of  the  open  systems  standards  used  for  the 
Internet  and  the  Defense  Information  System  Network  (DISN). 

□  Information  Modeling,  Metadata,  and  Information  Exchange  Standards:  Section  4  describes  the 
use  of  integrated  information  modeling  and  mandates  applicable  standards.  Information 
modeling  consists  of  activity,  data,  and  object  modeling.  This  section  also  mandates 
information  standards,  including  message  formats. 

□  Human-Computer  Interface  Standards:  Section  5  provides  a  common  framework  for 
Human-Computer  Interface  (HCI)  design  and  implementation  in  DoD  systems.  The  objective 
is  the  standardization  of  user  interface  implementation  options,  enabling  DoD  applications  to 
appear  and  behave  in  a  reasonably  consistent  manner. 

□  Information  Security  Standards:  Section  6  prescribes  the  standards  and  protocols  to  be  used  to 
satisfy  security  requirements.  This  section  provides  the  mandated  and  emerging  security 
standards  that  apply  to  JTA  Sections  2  through  5. 

1.7.3  Domains  and  Subdomains 

The  JTA  Core  contains  the  common  service  areas,  interfaces,  and  standards  (the  JTA  elements) 
applicable  to  all  DoD  systems  to  support  interoperability.  Recognizing  that  there  are  additional  JTA 
elements  common  within  families  of  related  systems  (i.e.,  domains),  the  JTA  adopted  the  notion  of 
domain  and  subdomain.  A  domain  represents  a  grouping  of  systems  sharing  common  functional, 
behavioral,  and  operational  requirements.  JTA  domains  and  subdomains  are  intended  to  exploit  the 
common  service  areas,  interfaces,  and  standards  supporting  interoperability  across  systems  within  the 
domain  and/or  subdomain. 

A  JTA  domain  contains  domain-specific  JTA  elements  applicable  within  the  specified  family  of 
systems  to  further  support  interoperability  within  the  systems  represented  in  the  domain — in  addition  to 
those  included  in  the  JTA  Core.  A  domain  may  be  composed  of  multiple  subdomains.  Subdomains 
represent  the  decomposition  of  a  domain  (referred  to  as  the  subdomain’s  “parent”  domain)  into  a  subset 
of  related  systems,  exploiting  additional  commonalities,  and  addressing  variances  within  the  domain.  A 
subdomain  contains  domain-specific  JTA  elements  applicable  within  the  specified  family  of  systems  to 
further  support  interoperability  within  the  systems  represented  in  the  subdomain — in  addition  to  those 
included  in  the  JTA  Core  and  in  the  parent  domain.  The  relationships  between  the  JTA  Core,  domains, 
and  subdomains  currently  in  the  JTA  are  illustrated  in  Figure  1-2. 

The  current  domains  and  subdomains  are  listed  as  follows: 

□  Domains 

■  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and 
Reconnaissance  (C4ISR) 

■  Combat  Support  (CS) 

■  Modeling  and  Simulation  (M&S) 

■  Weapon  Systems  (WS) 
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Figure  1-2:  JTA  Hierarchy  Model 


□  Subdomains 

■  Automatic  Test  Systems  (ATS) 

■  Aviation  (AV) 

■  Cryptologic  (CRY) 

■  Defense  Transportation  System  (DTS) 

■  Ground  Vehicles  (GV) 

■  Human  Resources  (HR) 

■  Medical  (MED) 

■  Missile  Defense  (MD) 

■  Missile  Systems  (MS) 

■  Munition  Systems  (MUS) 

■  Soldier  Systems  (SS) 

■  Space  Reconnaissance  (SR) 
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A  program  manager  or  engineer  specifying  or  applying  JTA  standards  for  a  specific  system  will  first 
select  all  appropriate  JTA  Core  elements,  and  then  those  included  in  the  relevant  domain  and 
subdomain. 

Each  domain  and  subdomain  includes  an  introduction  clearly  specifying  the  purpose,  scope,  and 
description  of  the  domain,  and  the  background  of  the  domain  and  subdomain.  As  necessary,  each 
domain  and  subdomain  provides  a  list  of  domain-specific  standards  and  guidance  in  a  format  consistent 
with  the  JTA  Core.  Domains  and  subdomains  generally  use  the  DoD  Technical  Reference  Model 
(TRM)  defined  in  1 .8,  but  may  also  use  a  different,  tailored,  or  an  expanded  model. 

1.7.4  Appendices  (Appendix  A,  B,  C,  D) 

The  appendices  provide  supporting  information  and  links  to  standards  organizations’  Web  sites. 

Appendix  A:  Abbreviations  and  Acronyms  contains  a  list  of  abbreviations  and  acronyms. 

Appendix  B:  Document  Sources  is  a  list  of  the  organizations  from  which  documents  cited  in  the  JTA 
may  be  obtained. 

Appendix  C:  References  is  a  list  of  documents  (e.g.,  a  memorandum  or  a  publication)  that  directs  the 
reader  to  a  source  of  more  information  on  a  subject. 

Appendix  D:  Glossary  is  a  list  of  terms  with  their  meanings. 

The  DoD  Joint  Technical  Architecture  List  of  Mandated  and  Emerging  Standards  (LMES),  now  a 
stand-alone  document  on  the  JTA  Web  site,  contains  “currently  mandated,”  “currently  preferred,”  and 
“emerging”  standards  for  each  JTA  service  area. 

1.8  DoD  Technical  Reference  Model 

The  DoD  Technical  Reference  Model  (TRM),  Version  2.0,  9  April  2001,  and  the  core  set  of  standards 
mandated  in  the  JTA  define  the  target  technical  environment  for  the  acquisition,  development,  and 
support  of  DoD  information  technology  (IT).  The  purpose  of  the  TRM  is  to  provide  a  common 
conceptual  framework  and  a  common  vocabulary  so  that  the  diverse  components  within  DoD  can  better 
coordinate  acquisition,  development,  and  support  of  DoD  IT.  Interoperability  is  dependent  on  the 
establishment  of  a  common  set  of  services  and  interfaces  that  system  developers  can  use  to  resolve  TAs 
and  related  issues. 

The  TRM  structure  is  intended  to  reflect  the  separation  of  data  from  applications  and  applications  from 
the  computing  platform — a  key  principle  in  achieving  open  systems.  The  JTA  has  adapted  the  TRM  to 
serve  as  the  framework  for  presenting  JTA-mandated  standards.  The  JTA’s  use  of  the  TRM  ensures  the 
use  of  consistent  definitions  needed  to  define  architectural  and  design  components.  The  model 
identifies  service  areas  (i.e.,  a  set  of  capabilities  grouped  by  functions)  and  their  interfaces.  The  TRM 
was  chosen  as  the  framework  of  the  JTA  because  of  the  model’s  inherent  support  of  open  system 
concepts.  As  illustrated  in  Figure  1-3,  the  model  is  partitioned  into  the  following:  an  Application 
Software  entity  that  includes  both  User  Applications  and  Support  Applications;  an  Application 
Platform  entity  that  contains  the  system  services  (e.g.,  User  Interface  and  Data  Management  services) 
and  Operating  System  services,  Physical  Environment  Services,  External  Environment,  and  a  number 
of  interfaces.  The  interfaces  provide  support  for  a  wide  range  of  applications  and  configurations  and 
consist  of  the  following:  Application  Program  Interfaces  (APIs)  and  External  Environment 
Interfaces  (EEIs). 
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Services  View  Interface  View 


Environment 


Figure  1-3:  DoD  Technical  Reference  Model  (TRM) 


The  following  JTA  Core  services  are  equivalent  to 
within  the  Application  Platform  entity: 

Software  Engineering  Services 
User  Interface  Services 
Data  Management  Services 
Data  Interchange  Services 
Graphics  Services 
Platform  Communications  Services 


their  corresponding  TRM  system  services  contained 

Security  Services 
System  Management  Services 
Distributed  Computing  Services 
Internationalization  Services 
Operating  System  Services 
Physical  Environment  Services 


The  relationship  between  the  sections  in  the  JTA  and  the  TRM  service  areas  are  as  follows: 

Section  2,  Information  Processing  Standards,  specifies  standards  for  the  User  Interface,  Data 
Management,  Data  Interchange,  Graphics,  Operating  System,  Internationalization,  System 
Management,  Distributed  Computing  and  Environment  Management  service  areas.  This  section  also 
references,  but  does  not  specify,  any  standards  for  the  Software  Engineering,  Communications 
(e.g.,  Platform,  Applications,  and  External  Environment),  and  Security  service  areas. 

Section  3,  Information  Transfer  Standards,  specifies  standards  for  the  Communications  and  Network 
and  System  Management  service  areas  applicable  to  both  system  and  network  management. 

Section  4,  Information  Modeling,  Metadata,  and  Information  Exchange  Standards,  addresses  standards 
for  an  area  that  is  not  currently  elaborated,  but  is  supported  by  engineering  support,  data  management, 
and  software  engineering  services  in  the  TRM. 
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Section  5,  Human-Computer  Interface  Standards,  complements  those  cited  for  User  Interface  Services. 

Section  6,  Information  Security  Standards,  specifies  security  standards  that  are  relevant  to  the  service 
areas  discussed  in  Section  2,  Section  3,  and  Section  5. 

Table  1-1  provides  the  interface  relationships  for  Figure  1-3. 


Table  1-1:  Interface  Translation  Table 


Interface 

Type 

Definition 

ID 

Physical  Resources  (Direct) 

1 L 

Physical  Resources  (Logical) 

2D 

Resources  -  Physical  (Direct) 

2L 

Resource  Access  (Logical) 

3D 

System  Service  -  Resource  Access  (Direct) 

3L 

System  Service  (Logical) 

3X 

Operating  System  -  Extended  OS  (Direct) 

4D 

Applications  -  System  Services  (Direct) 

4L 

Applications  -  Peer  (Logical) 

4X 

Applications  -  Support  Services  (Direct) 

At  this  time,  the  JTA  does  not  include  standards  for  all  of  the  services  identified  in  the  TRM. 

1.9  Key  Considerations  in  Using  the  JTA 

The  JTA  is  used  to  determine  the  mandated  standards  within  applicable  service  areas  for 
implementation  within  new  or  upgraded  systems.  However,  there  are  several  key  considerations  in 
using  the  JTA. 

The  mandatory  standards  in  the  JTA  must  be  implemented  or  used  by  systems  that  have  a  need  for  the 
corresponding  JTA  service/interface.  A  standard  is  mandatory  in  the  sense  that  if  a  service/interface  is 
going  to  be  implemented,  it  shall  be  implemented  in  accordance  with  the  associated  standard.  If  a 
required  service/interface  can  be  obtained  by  implementing  more  than  one  standard  (e.g.,  operating 
system  standards),  the  appropriate  standard  should  be  selected  based  on  system  requirements. 

The  JTA  is  a  forward-looking  document.  It  guides  the  acquisition  and  development  of  new  and 
emerging  functionality  and  provides  a  baseline  toward  which  existing  systems  will  move.  It  is  the 
minimal  set  of  essential  standards  (for  interfaces/services)  that  should  be  used  now  and  in  the  future.  It 
is  not  a  catalog  of  all  information  technology  standards  used  within  today’s  DoD  systems.  If  legacy 
standards  are  needed  to  interface  with  existing  systems,  they  can  be  implemented  on  a  case-by-case 
basis  in  addition  to  the  mandated  standard. 

The  JTA  delineates  mandatory  standards  and  guidelines  in  Volume  I.  In  addition,  selected  services  and 
functions  are  identified  with  a  sunset  clause  and,  thus,  will  be  removed  as  indicated  above.  The 
continued  use  of  sunset  standards  is  discouraged.  Volume  2  of  the  JTA  Version  6.0  lists  emerging, 
net-centric  standards  and  guidelines  to  be  used  as  reference  material  for  the  acquisition  community,  but 
they  should  not  be  adhered  to  until  they  become  mandatory  in  future  versions  of  the  JTA. 
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1.10  JTA  Relationship  to  the  Defense  Standardization  Program 

The  Defense  Standardization  Program  (DSP)  provides  the  policy  framework  and  technical 
infrastructure  for  developing  DoD  specifications  and  standards  and  for  participating  in  the  development 
and  adoption  of  commercial  non-government  standards  and  standards  promulgated  by  other  federal 
agencies  and  multinational  treaty  organizations.  These  standards  provide  a  foundation  for  the  JTA, 
which  serves  as  a  tool  for  the  selection  and  application  of  standards  developed  or  adopted  under  the 
DSP  that  arc  essential  for  achieving  joint  information  interoperability.  While  the  JTA  provides  technical 
direction  in  the  selection  of  standards,  such  selection  is  based  on  standards  application  policies 
prescribed  by  DoD  4120.24-M,  “Defense  Standardization  Program  (DSP)  Policies  and  Procedures.” 
Consistent  with  these  policies,  the  JTA  mandates  the  minimum  standards  necessary  to  achieve  joint 
interoperability  and  implements  commercial  standards  and  practices  to  the  maximum  extent  possible. 
Use  of  JTA-mandated  standards  or  specifications  in  acquisition  solicitations  will  not  require  a  waiver 
from  standards  reform  policies  since  all  mandatory  standards  in  the  JTA  arc  of  the  types  that  have  been 
identified  by  DoD  standards  reform  as  waiver-free  or  for  which  an  exemption  has  already  been 
obtained. 

1.11  Standards  Selection  Criteria 

The  standards  selection  criteria  used  throughout  the  JTA  focus  on  mandating  only  those  items  critical 
to  interoperability  that  are  based  primarily  on  commercial  open  system  technology,  are  implementable, 
and  have  strong  support  in  the  commercial  marketplace.  Standards  will  only  be  mandated  if  they  meet 
all  of  the  following  criteria: 

□  Interoperability:  They  are  essential  in  providing  joint  and  potentially  combined 
Service/ Agency  information  exchange  and  support  joint  activities. 

□  Maturity:  They  arc  technically  mature  (strong  support  in  the  commercial  marketplace)  and 
stable. 

□  Implementability:  They  are  technically  implementable. 

□  Public:  They  arc  publicly  available. 

□  Consistent  with  Authoritative  Source:  They  are  consistent  with  law,  regulation,  policy,  and 
guidance  documents. 

□  Non-Proprietary:  They  are  not  proprietary. 

□  Network  Centric:  They  arc  consistent  with  DoD’s  vision  for  Network  Centric  Operational 
Warfare  (NCOW). 

The  following  preferences  were  used  to  select  standards: 

□  Standards  that  arc  commercially  supported  in  the  marketplace  with  validated  implementations 
available  in  multiple  vendors’  mainstream  commercial  products  took  precedence. 

□  Publicly  held  standards  were  generally  preferred. 

□  International  or  national  industry  standards  were  preferred  over  military  or  other  government 
standards. 

□  Standards  that  can  be  implemented  without  requiring  intellectual  property  (i.e.,  patent)  rights 
were  generally  preferred. 
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□  Many  standards  have  optional  parts  or  parameters  that  can  affect  interoperability.  In  some 
cases,  an  individual  standard  may  be  further  defined  by  a  separate,  authoritative  document 
called  a  “profile”  or  a  “profile  of  a  standard,”  which  further  refines  the  implementation  of  the 
original  standard  to  ensure  proper  operation  and  assist  interoperability. 

□  The  word  “standard”  as  referred  to  in  the  JTA  is  a  generic  term  for  the  collection  of  documents 
cited  herein.  An  individual  “standard”  is  a  document  that  establishes  uniform  engineering  and 
technical  requirements  for  processes,  procedures,  practices,  and  methods.  A  standard  may  also 
establish  requirements  for  selection,  application,  and  design  criteria  of  material.  The  standards 
cited  in  the  JTA  may  include  commercial,  federal,  and  military  standards  and  specifications, 
and  various  other  kinds  of  authoritative  documents  and  publications. 

1.12  Configuration  Management 

Maintenance  of  the  JTA  is  conducted  by  the  JTA  Development  Group  (JTADG),  directed  by  the 
Technical  Architecture  Steering  Group  (TASG),  and  approved  by  the  DoD  CIO.  Members  involved  in 
the  effort  represent  the  DoD  Components — Office  of  the  Secretary  of  Defense  (OSD),  the  Military 
Services,  the  Office  of  the  Joint  Chiefs  of  Staff  (OJCS),  the  Unified  and  Specified  Combatant 
Commands,  the  Defense  Agencies,  and  components  of  the  Intelligence  Community.  Table  1-2  shows 
the  organizations  that  have  voting  memberships  in  the  JTADG  and  TASG.  However,  by  the  authority 
vested  in  the  Department’s  CIO,  this  entity  will  have  the  final  decision-making  authority  to  determine 
which  standards  are  mandatory,  sunset,  or  removed  from  future  versions  of  the  JTA.  It  will  be  the  goal 
of  the  CIO,  working  in  collaboration  with  the  Services,  Agencies,  and  components  of  the  DoD  and  with 
the  Intelligence  Community,  that  the  JTA  remain  a  minimal  set  of  primarily  commercial-based 
standards  that  will  guide  the  evolution  of  the  GIG  toward  becoming  an  enterprise-wide  infrastructure 
supporting  all  DoD  activities  from  national  security  to  e-Business. 

The  JTA  is  an  evolving  knowledge  base  and  will  keep  pace  with  the  technologies,  marketplace,  and  the 
associated  standards  upon  which  it  is  based. 

The  JTA  Management  Plan  describes  the  process  by  which  the  JTA  will  be  configuration-managed. 
This  document,  as  well  as  the  charter  for  the  JTADG,  may  be  found  on  the  Defense  Information 
Systems  Agency  (DISA)  Interoperability  Directorate  (IN)  JTA  Web  site  at:  http://jta.disa.mil. 

Suggested  changes  to,  or  comments  on,  the  JTA  originating  from  DoD  Components  (Office  of  the 
Secretary  of  Defense  [OSD],  the  Military  Departments,  the  Office  of  the  Joint  Chiefs  of  Staff  [OJCS], 
the  Unified  and  Specified  Combatant  Commands,  and  the  Defense  Agencies)  should  be  submitted  via 
the  appropriate  official  JTA  Component  Representative  listed  on  the  JTA  Web  site.  These 
representatives  will  integrate  and  coordinate  change  requests  for  submission  as  official  DoD 
Component- sponsored  change  requests. 

Where  a  standard  is  highlighted  and  underscored,  it  is  hyperlinked  to  a  Web  site  with  information  about 
the  standard. 

To  submit  a  change  request,  register  online  as  a  user  at:  http://jtaonline.disa.mil. 
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Table  1-2:  JTA  Development  Group  (JTADG)  Voting  Membership 


Defense  Advanced  Research  Projects  Agency  (DARPA) 

Defense  Information  Systems  Agency  (DISA) 

Defense  Intelligence  Agency  (DIA) 

Defense  Logistics  Agency  (DLA) 

Defense  Modeling  and  Simulation  Office  (DMSO) 

Defense  Threat  Reduction  Agency  (DTRA) 

Joint  Staff/J6 

Missile  Defense  Agency  (MDA) 

National  Imagery  and  Mapping  Agency  (NIMA) 

National  Reconnaissance  Office  (NRO) 

National  Security  Agency  (NSA) 

Office  of  the  Assistant  Secretary  of  Defense  (C3I) 

Office  of  the  Under  Secretary  of  Defense  (AT&L)  OSJTF 

U.S.  Air  Force  (USAF) 

U.S.  Army  (USA) 

U.S.  Coast  Guard  (USCG) 

U.S.  Marine  Corps  (USMC) 

U.S.  Navy  (USN) 

U.S.  Special  Operations  Command  (USSOCOM) 

U.S.  Transportation  Command  (USTRANSCOM) 
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2.1  Introduction 

Information  processing  standards  and  profiles  are  described  in  this  section.  These  standards  promote 
seamless  information  processing  interoperability  for  Department  of  Defense  (DoD)  systems. 

2.2  Purpose 

The  purpose  of  this  section  is  to  specify  the  Joint  Technical  Architecture  (JTA)  government  and 
commercial  information  processing  standards  the  DoD  will  use  to  develop  integrated,  interoperable 
systems  that  directly  or  indirectly  support  the  warfighter. 

2.3  Scope  (Applicability) 

This  section  applies  to  user  applications,  support  applications,  and  application  platform  service 
software.  This  section  does  not  cover  communications  standards  needed  to  transfer  information 
between  systems  (defined  in  Section  3),  nor  standards  relating  to  information  modeling  (i.e.,  process, 
data,  and  simulation),  data  elements,  or  military-unique  message  set  formats  (defined  in  Section  4). 

2.4  Background 

Information  processing  standards  provide  the  data  formats  and  instruction-processing  specifications 
required  to  represent  and  manipulate  data  to  meet  information  technology  (IT)  mission  needs.  The 
standards  in  this  section  are  drawn  from  widely  accepted  commercial  standards  that  meet  DoD 
requirements.  Where  necessary  for  interoperability,  profiles  of  commercial  standards  are  used.  Military 
standards  are  mandated  only  when  suitable  commercial  standards  are  not  available. 

2.5  Information  Processing  Services 

The  information  processing  standards  in  this  section  apply  to  support  applications,  system  services,  and 
operating  system  services  that  arc  contained  in  the  Application  Software  and  Application  Platform 
Entities  of  the  TRM  (see  1.8). 

2.5.1  Software  Engineering  Services 

The  software  engineering  services  provide  system  developers  with  the  tools  that  are  appropriate  to  the 
development  and  maintenance  of  applications.  Language  services  provide  the  basic  syntax  and 
semantic  definition  for  developers  to  encode  the  desired  software  functions.  DoD  programs  should 
design  and  develop  software  based  on  the  application  of  systems  and  software  engineering  best 
practices.  Programming  language  selections  should  be  made  in  the  context  of  the  system  and  software 
engineering  factors  to  minimize  overall  life-cycle  costs  and  risks  and  to  maximize  potential 
interoperability.  Computer  languages  should  be  used  in  such  a  way  as  to  minimize  changes  when 
compilers,  operating  systems,  or  the  hardware  change.  To  maximize  portability,  the  software  should  be 
structured  where  possible  so  it  can  be  easily  ported. 

2.5.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.2  User  Interface  Services 

User  Interface  Services  implement  the  Human-Computer  Interface  (HCI)  style  and  control  how  users 
interact  with  the  system  by  providing  consistent  access  to  application  programs,  operating  system 
functions,  and  system  utilities. 
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2.5.2. 1  User  Interface  Service — POSIX 

For  Portable  Operating  System  Interface  for  Computer  Environments  (POSIX)-based  systems,  the 
Common  Desktop  Environment  (CDE)/Motif  provides  a  common  set  of  desktop  applications  and 
management  capabilities.  CDE/Motif  uses  the  underlying  X- Windows  system. 

2.5.2.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2. 5. 2.2  User  Interface  Service — Win32 

For  Microsoft  Windows-based  systems,  the  Win32  Application  Program  Interface  (API)  set  provides 
user  interface  services.  Documentation  for  the  Win32  APIs  is  found  within  the  Microsoft  Platform 
Software  Development  Kit  (SDK). 

2.5.2.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.3  Data  Management  Services 

Central  to  most  systems  is  the  sharing  of  data  between  applications.  The  data  management  services 
provide  for  the  independent  management  of  data  shared  by  multiple  applications. 

2.5.3(a)  Emerging.  Parts  one  through  five  of  the  emerging  SQL3  specification  were  completed  in 
December  1999  and  contain  a  number  of  data  abstraction  facilities,  including  user-defined  data  types 
and  methods.  The  emerging  SQL  specification  also  contains  facilities  for  defining  and  referencing 
object  identifiers.  Additionally,  the  emerging  SQL3  specification  supports  knowledge-based  data 
management  and  remote  data  access  capabilities.  The  following  SQL3  standards  are  emerging  and  have 
been  completed  and  approved  by  ANSI,  ISO,  and  IEC: 

-  ANSI/ISO/IEC  9075-1:1999,  Information  technology  -  Database  languages  -  SQL  -  Part  1 : 
Framework  (SQL/Framework). 

-  ANSI/ISO/IEC  9075-2:1999,  Information  technology  -  Database  languages  -  SQL  -  Part  2: 
Foundation  (SQL/Foundation). 

-  ANSI/ISO/IEC  9075-3:1999,  Information  technology  -  Database  languages  -  SQL  -  Part  3: 
Call-Level  Interface  (for  SQL3). 

-  ANSI/ISO/IEC  9075-4:1999,  Information  technology  -  Database  languages  -  SQL  -  Part  4: 
Persistent  Stored  Modules  (SQL/PSM). 

-  ANSI/ISO/IEC  9075-5:1999,  Information  technology  -  Database  languages  -  SQL  -  Part  5: 
Host  Language  Bindings  (SQL/Bindings). 

Additionally,  ISO/IEC  DIS  9075-9  through  ISO/IEC  DIS  9075-12  are  in  progress  though  they  have  not 
been  completed. 

SQL  Multimedia  (SQL/MM)  is  a  set  of  extensions  to  the  SQL3  specification  and  will  specify  packages 
of  SQL  abstract  data  type  (ADT)  definitions  using  the  facilities  for  ADT  specification  and  invocation 
provided  in  the  SQL3  specification.  SQL/MM  intends  to  standardize  class  libraries  for  science  and 
engineering;  full-text  and  document  processing;  and  methods  for  the  management  of  multimedia 
objects  such  as  image,  sound,  animation,  music,  and  video.  The  emerging  standard  for  SQL/MM  is: 

-  ISO/IEC  13249-3:1999  Information  technology  -  Database  languages  -  SQL  multimedia  and 
application  packages  -  Part  3:  Spatial. 

The  SQL-RDA  standard  specifies  a  message  format  for  remote  communication  of  SQL  database 
language  statements  (query  and  update)  to  a  remote  database.  The  specification  defines  uses  of  the 
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message  fields  and  other  implementation  information  including  sequencing  and  how  SQL  statements 
map  to  the  Remote  Database  Access  (RDA)  protocol,  a  TCP/IP-compatible  communications  protocol 
that  enables  a  database  client  to  gain  access  to  database  servers.  The  emerging  standard  for  SQL  -  RDA 
is: 


-  I  SO/I  EC  9579:2000,  Information  technology  -  Remote  database  access  for  SQL  with  security 
enhancement. 

The  Object  Database  Management  Group  (ODMG)  has  published  a  third  version  of  their  standard  for 
an  Object  Storage  API  that  can  work  with  any  DBMS  or  tool.  The  ODMG  has  defined  a  comprehensive 
object  model,  described  an  object  specification  language,  defined  an  object  interchange  format,  defined 
an  object  query  language  (based  on  the  relational  query  language,  SQL)  and  worked  to  make  the 
programming  language  bindings  consistent  with  the  ODMG  model.  Version  3.0  improves  the  ODMG 
model,  enhances  the  Java  bindings,  and  broadens  the  standard  for  use  by  object-relational  mapping 
systems  as  well  as  for  object  DBMSs.  The  following  standard  is  emerging: 

-  The  Object  Database  Standard:  ODMG  3.0,  R.G.G.  Cattell  et  al,  eds.  The  Morgan  Kaufmann 
Series  in  Data  Management,  2000,  ISBN  1-55860-647-4. 

2.5.4  Data  Interchange  Services 

The  data  interchange  services  provide  specialized  support  for  the  exchange  of  data  between 
applications  and  to  and  from  the  external  environment.  These  services  include  document,  graphics  data, 
geospatial  data,  still  imagery  data,  motion  imagery  data,  audio  data,  storage  media,  atmospheric  and 
oceanographic  data,  time-of-day  data,  and  multimedia  data. 

2.5.4. 1  Document  Interchange 

The  document  interchange  service  specifies  the  supported  data  structures  to  be  used  for  storage  of 
electronic  information  and  its  transmission  between  information  systems.  Document  formats  are  not 
restricted  to  physical  byte  layout  for  a  file,  but  also  include  the  languages  used  to  instruct  information 
systems  on  how  to  display  the  document  information. 

2.5.4.1(a)  Emerging.  XHTML  (Extensible  HyperText  Markup  Language)  is  the  next-generation 
follow-on  to  HTML.  XHTML  reformulates  HTML  as  an  XML  application,  bringing  the  modular 
capabilities  of  XML  to  Web  development.  A  single  XML  data  stream  can  be  used  by  a  variety  of 
applications  to  support  multiple  devices,  such  as  cellular  telephones,  computers,  Web  television,  and 
embedded  applications  simply  by  processing  the  needed  XHTML  tags  within  the  XML  data  stream. 
The  following  standard  is  emerging: 

-  XHTML™  1.0:  The  Extensible  HyperText  Markup  Language,  Second  Edition,  A  Reformulation 
of  HTML  4  in  XML  1 .0,  W3C  Recommendation,  26  January  2000,  revised  1  August  2002. 

XForms  architecture  separates  puipose  (semantics)  from  presentation  (syntax),  and  associates  the 
capabilities  of  XML  and  the  ease  of  HTML  for  a  wide  range  of  devices.  The  following  standards  are 
emerging: 

-  XForms  1.0,  W3C  Working  Draft,  1 2  November  2002. 

-  XForms  Requirements  W3C  Working  Draft,  4  April  2001 . 

Resource  Description  Framework  (RDF)  describes  a  foundation  for  processing  Web-based  metadata;  it 
supports  interoperability  between  different  applications  that  may  need  to  exchange 
machine-understandable  information  on  the  World  Wide  Web.  RDF  uses  XML  for  encoding  its 
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interchange  syntax.  RDF  is  a  model  for  representing  named  properties  (attributes  of  resources), 
property  values,  and  relationships  between  properties.  An  RDF  model  can  resemble  an 
entity-relationship  diagram  or  virtually  any  other  information  structure  that  can  be  depicted  as  a 
directed  graph.  The  following  standard  is  emerging: 

-  Resource  Description  Framework  (RDF)  Model  and  Syntax  Specification,  W3C 
Recommendation,  22  February  1999,  REC-rdf-syntax-1 9990222. 

The  RDF  Schema  specification  provides  a  machine-understandable  system  for  defining  “schemas”  for 
descriptive  vocabularies  like  the  Dublin  Core,  a  set  of  15  metadata  elements  believed  to  be  broadly 
applicable  to  describing  Web  resources  to  enable  their  discovery.  It  allows  designers  to  specify  classes 
of  resource  types  and  properties  to  convey  descriptions  of  those  classes,  and  constraints  on  the  allowed 
combinations  of  classes,  properties,  and  values  within  a  data  stream.  This  has  the  effect  of  providing  a 
machine-understandable  means  of  exchanging  structured  and  structural  information  with  respect  to 
various  persistent  entities,  such  as  DBMSs  with  XML.  The  following  standard  is  emerging: 

-  Resource  Description  Framework  (RDF)  Schema  Specification  1.0,  W3C  Candidate 
Recommendation,  27  March  2000,  CR-rdf-schema-20000327. 

A  Working  Draft  of  the  Extensible  Stylesheet  Language  (XSL)  Version  1.0  (Ref:  WD-xsl-19981216, 
16  December  1998)  is  being  defined  in  the  World  Wide  Web  Consortium.  XSL  will  be  used  where 
powerful  formatting  capabilities  are  required  or  for  formatting  highly  structured  information  such  as 
XML-structured  data  or  XML  documents  that  contain  structured  data.  The  new  capabilities  provided  by 
the  XSL  proposal  include:  the  formatting  of  source  elements  based  on  ancestry/descendency,  position, 
and  uniqueness;  the  creation  of  formatting  constructs  including  generated  text  and  graphics;  the 
definition  of  reusable  formatting  macros;  direction- writing,  independent  stylesheets;  and  extensible  set 
of  formatting  objects. 

XSL  uses  XML  syntax  and  combines  formatting  features  from  Document  Style  and  Semantics 
Specification  Language  (DSSSL).  The  following  standard  is  emerging: 

-  Extensible  Stylesheet  Language  (XSL),  Version  1.0,  W3C  Recommendation, 

15  October  2001. 

XML  Stylesheet  Language  Transformations  (XSLT)  is  a  language  for  transforming  XML  documents 
into  other  XML  documents  and  is  used  as  a  transformation  part  of  XSL.  XSLT  has  also  been  designed 
to  be  used  independently,  but  is  used  primarily  with  XSL.  The  following  standard  is  emerging: 

-  XSL  Transformations  (XSLT),  Version  1 .1 ,  W3C  Working  Draft,  24  August  2001 . 

XPath  is  a  language  for  addressing  parts  of  an  XML  document,  designed  to  be  used  by  XSLT.  The 
following  standard  is  emerging. 

-  XML  Path  Language  (XPATH),  Version  1.0,  W3C  Recommendation,  16  November  1999. 

For  applying  an  XML-encoded  digital  signature  within  an  XML  document,  rather  than  as  separate  data, 
the  following  standard  is  emerging: 

-  XML-Signature  Syntax  and  Processing,  W3C  Recommendation,  12  February  2002. 
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Xquery  provides  flexible  query  facilities  to  extract  data  from  collections  of  XML  documents  as  well  as 
non-XML  data  viewed  as  XML  via  a  mapping  mechanism.  The  following  standard  is  emerging: 

-  XQuery  1 .0,  An  XML  Query  Language.  W3C  Working  Draft,  15  November  2002. 

Web  Services  Description  Language  defines  the  XML  grammar  needed  for  network  services  for 
distributed  systems  and  provides  the  methods  for  automating  the  details  involved  in  applications 
communication.  The  following  standard  is  emerging: 

-  Web  Services  Description  Language  (WSDL)  1.1,  W3C  Note,  1 5  March  2001 . 

Simple  Object  Access  Protocol  (SOAP)  is  a  lightweight  XML  protocol  used  for  exchanging 
information  in  a  decentralized,  distributed  environment.  It  provides  a  simple  method  of  enveloping  and 
transferring  an  XML  document  using  HTTP  transfer  protocol,  and  addressing  the  recipient  using 
Uniform  Resource  Identifiers  (URI).  The  following  standard  is  emerging: 

-  Simple  Object  Access  Protocol  (SOAP)  1.1,  W3C  Note,  08  May  2000. 

For  publishing  and  discovery  of  Web  services,  the  following  standard  is  emerging.  Note  that  there  arc 
significant  security  issues  that  need  to  be  considered  before  using  this  standard: 

-  UDDI  Version  3.0  Published  Specification,  1 9  July  2002. 

Cascading  Style  Sheets  (CSS)  provides  a  simple  approach  for  formatting  documents.  CSS  lacks 
XSL/XSLT’s  ability  to  reorder  information,  but  CSS  can  incrementally  format  documents  and  can 
handle  HTML.  For  simple  formatting  of  HTML  and  XML  documents  (where  XSL’s  capabilities  are  not 
needed),  the  following  is  emerging: 

-  Cascading  Style  Sheets  (CSS)  Level  1  (CSS1  W3C  Recommendation,  17  December  1996. 

There  are  different  approaches  for  accessing  XML  data,  e.g.,  the  Simple  API  for  XML  (SAX)  approach 
is  used  for  sequential  access  and  the  Java  Document  Object  Model  (JDOM)  approach  is  used  for  a 
Java-specific  binding  of  Document  Object  Model  (DOM).  For  read/write  random  access  to  XML 
documents,  the  following  standard  is  emerging: 

-  Document  Object  Model  (DOM)  Level  1  Specification,  Version  1.0,  W3C  Recommendation, 

1  October  1998. 

2. 5. 4.2  Common  Document  Interchange  Formats 

2.5.4.2(a)  Emerging.  Industry  standard  formats  shah  be  used  for  interchange  of  common  document 
types. 

2.5.4.3  Graphics  Data  Interchange 

These  services  are  supported  by  device-independent  descriptions  of  the  picture  elements  for  vector  and 
raster  graphics.  The  International  Organization  for  Standardization  (ISO)  Joint  Photographic  Expert 
Group  (JPEG)  standard  describes  several  alternative  algorithms  for  the  representation  and  compression 
of  raster  images,  particularly  for  imagery;  JPEG  images  may  be  transferred  using  the  JPEG  File 
Interchange  Format  (JFIF).  Graphics  Interchange  Format  (GIF)  and  JFIF  are  de  facto  standards  for 
exchanging  graphics  and  images  over  an  Internet.  GIF  supports  lossless-compressed  images  with  up  to 
256  colors  and  short  animation  segments.  Note  that  Unisys  owns  a  related  patent,  which  requires  a 
license  for  software  that  writes  the  GIF  format.  Portable  Network  Graphics  (PNG)  is  an  extensible  file 
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format  for  the  lossless,  portable,  well-compressed  storage  of  a  raster  image.  Indexed-color,  grayscale, 
and  truecolor  images  are  supported,  plus  an  optional  alpha  channel  for  transparency. 

2.5.4.3(a)  Emerging.  The  Virtual  Reality  Modeling  Language  (VRML)  is  a  commercial  standard  with 
capabilities  for  3-D  representation  of  data.  The  following  standard  is  emerging: 

-  ISO/IEC  14772-1:1998,  Information  technology  -  Computer  graphics  and  image  processing  - 
The  Virtual  Reality  Modeling  Language  (VRML)  -  Part  1:  Functional  specification  and  UTF-8 
encoding. 

The  Multiple-image  Network  Graphics  (MNG)  format  is  an  extension  to  the  PNG  format,  developed  by 
the  PNG  Development  Group,  for  the  storage  and  transmission  of  animated  graphics  and  complex  still 
images.  It  was  designed  to  replace  GIF  animation  with  a  true  animation  format.  The  following  standard 
is  emerging: 

-  Multiple-image  Network  Graphics  (MNG)  Format,  Version  1 .0,  31  January  2001 . 

The  PNG  1.2  specification  is  currently  in  the  Final  Committee  draft  (FCD)  stage  with  the  ISO/IEC.  The 
following  is  an  emerging  standard: 

-  ISO/IEC  15948:2000,  Portable  Network  Graphics  (PNG):  Functional  Specification  Final 
Committee  Draft  (FCD). 

2 .5.4.4  Environmental  Data  Interchange 

Most  environmental  data  is  available  from  producers  in  specific  product  formats.  As  information 
systems  become  more  capable,  the  need  to  integrate  products  and  fuse  data  from  multiple  sources  is 
increasing.  A  product-independent  data  interchange  format  allows  product-specific  formats  to  be 
decomposed  into  foundation  data  for  potential  integration,  update,  and  fusion,  potentially  to  be 
recomposed  into  the  original  product  format. 

2.5.4.4(a)  Emerging.  Synthetic  Environment  Data  Representation  and  Interchange  Specification 
(SEDRIS)  facilitates  interoperability  among  heterogeneous  information  technology  applications  by 
providing  complete  and  unambiguous  interchange  of  environment  data.  SEDRIS  provides  a  standard 
interface  for  Geographic  Information  System  (GIS)  systems,  which  are  key  components  in  the 
generation  of  complex  integrated  environmental  databases.  The  SEDRIS  data  interchange  specification 
supports  the  pre-runtime  distribution  and  runtime  specification  of  source  data,  three-dimensional 
models,  and  integrated  databases  that  describe  the  physical  environment.  ISO/IEC  18023  provides  a 
standard  methodology  and  format  for  representing  environmental  information  and  for  its  transmittal 
and  exchange  between  information  systems.  ISO/IEC  18025  provides  a  standard  coding  system  for 
environmental  information  used  in  multiple  systems,  including  those  used  by  environmental  data 
collectors  and  producers.  ISO/IEC  18026  provides  a  set  of  spatial  reference  models,  both  earth-centric 
and  non-earth-centric  (for  application  to  celestial  bodies  other  than  the  planet  earth),  and  related 
coordinate  transformation  algorithms  for  use  in  standardizing  the  coordinate  systems  used  for 
collecting  and  displaying  environmental  information  within  the  requirements  of  MIL-STD-2401  and 
other  international  geospatial  coordinate  standards.  For  product  independent  environmental  data 
interchange,  the  following  standards  are  emerging: 

-  ISO/IEC  18023,  Information  technology  -  Computer  graphics  and  image  processing  - 
Synthetic  Environment  Data  Representation  and  Interchange  Specification  (SEDRIS), 

5  December  2001 . 
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-  ISO/I  EC  18025:  Information  technology  -  Computer  graphics  and  image  processing  - 
Environmental  Data  Coding  Specification  (EDCS),  26  December  2002. 

-  ISO/I  EC  18026:  Information  technology  -  Computer  graphics  and  image  processing  -  Spatial 
Reference  Model  (SRM),  14  January  2002. 

2.5.4. 4.1  Geospatial  Data  Interchange 

Geospatial  services  are  also  referred  to  as  mapping,  charting,  and  geodesy  (MC&G)  services. 
2.5.4.4.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2. 5.4.4. 2  Atmospheric  and  Oceanographic  Data  Interchange 

The  following  formats  are  established  by  the  World  Meteorological  Organization  (WMO)  Commission 
for  Basic  Systems  (CBS)  for  atmospheric  and  oceanographic  data. 

2.5.4.4.2(a)  Emerging.  Hierarchical  Data  Format  (HDF)  was  developed  by  the  National  Center  for 
Supercomputing  Applications  (NCSA)  to  facilitate  interchange  of  scientific  data.  It  is  used  in  many 
fields  including  environmental  science,  oceanography,  and  atmospheric  modeling.  It  emphasizes 
storage  and  I/O  efficiency  for  use  in  the  storage,  archiving  and  transmission  of  large  datasets  like 
images,  multidimensional  arrays,  structures  and  tables.  HDF  organizes  data  as  a  digraph,  with  Groups 
and  Datasets  as  primary  objects.  Secondary  and  tertiary  objects  can  be  created  for  subsetting  and 
assigning  parameters  to  data,  and  each  object  may  have  more  than  one  path  to  it.  HDF  provides  a  set  of 
APIs  which  can  be  used  to  access  the  data  or  subsets  without  knowledge  of  the  actual  format. 

For  large  or  complex  data  sets  that  are  interchanged  between  environmental  data  processing  systems, 
the  following  standard  is  emerging: 

-  Hierarchical  Data  Format  (HDF),  Version  5,  Release  1 .4.2,  National  Center  for  Super 
Computing  Applications,  4  October  2001 . 

2. 5. 4. 5  Still  Imagery  Data  Interchange 

The  National  Imagery  Transmission  Format  Standard  (NITFS)  is  a  DoD  and  Federal  Intelligence 
Community  suite  of  standards  for  the  exchange,  storage,  and  transmission  of  digital-imagery  products 
and  image-related  products.  Other  image  formats  can  be  used  internally  within  a  single  system; 
however,  NITFS  is  the  default  format  for  interchange  between  systems.  NITFS  provides  a  package 
containing  information  about  the  image,  the  image  itself,  and  optional  overlay  graphics.  The  standard 
provides  a  “package”  containing  an  image(s),  subimages,  symbols,  labels,  and  text  as  well  as  other 
information  related  to  the  image(s).  NITFS  supports  the  dissemination  of  secondary  digital  imagery 
from  overhead  collection  platforms.  Guidance  on  applying  the  suite  of  standards  composing  NITFS  can 
be  found  in  MIL-HDBK-1300A,  National  Imagery  Transmission  Format  Standard  (NITFS), 

12  October  1994. 

The  NITFS  allows  for  Support  Data  Extensions  (SDEs),  which  are  a  collection  of  data  fields  that 
provide  space  within  the  NITFS  file  structure  for  adding  functionality.  Documented  and  controlled 
separately  from  the  NITFS  suite  of  standards,  SDEs  extend  NITF  functionality  with  minimal  impact  on 
the  underlying  standard  document.  SDEs  may  be  incorporated  into  an  NITF  file  while  maintaining 
backward  compatibility  because  the  identifier  and  byte  count  mechanisms  allow  applications 
developed  prior  to  the  addition  of  newly  defined  data  to  skip  over  extension  fields  they  are  not  designed 
to  interpret.  These  SDEs  are  described  in  the  Compendium  of  Controlled  Extensions  (CE). 
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2.5.4.5(a)  Emerging.  The  Basic  Image  Interchange  Format  (BIIF)  is  a  published  international 
standard.  It  provides  a  commercial/international  foundation  for  interoperability  in  the  interchange  of 
imagery  and  imagery -related  data  among  applications.  BIIF  provides  a  data  format  container  for  image, 
symbol,  and  text,  along  with  a  mechanism  for  including  image -related  support  data.  The  following 
standard  is  emerging: 

-  ISO/I  EC  12087-5:1998  Information  technology  -  Computer  graphics  and  image  processing  - 
Image  Processing  and  Interchange  (I PI)  Functional  specification  -  Part  5:  Basic  Image 
Interchange  Format  (BIIF),  1  December  1998,  with  Technical  Corrigendum  1:2001. 

JPEG  2000  is  intended  to  provide  a  new  means  of  image  representation  containing  a  rich  set  of  features, 
all  supported  within  the  same  compressed  bit  stream.  Part  I  of  JPEG  2000  contains  mandatory  features. 
Part  II  of  JPEG  2000  is  a  Final  Draft  International  Standard  (FDIS)  that  contains  optional  features 
beyond  those  in  Part  I  including  advanced  region-of-interest  capability,  expanded  file  format, 
multispectral  compression,  low  complexity  implementation,  and  trellis  quantized  compression.  Only 
those  features  that  are  needed  for  specific  applications  need  be  implemented.  The  following  standard  is 
emerging: 

-  ISO/I  EC  15444-2:2001  JPEG  2000  image  coding  system,  July  2001 . 

2.5. 4. 6  Motion  Imagery  Data  Interchange 

Motion  Imagery  (MI)  is  defined  as  imaging  sensors/systems  that  generate/process  sequential  or 
continuous  streaming  images  at  specified  temporal  rates  (normally  expressed  as  Frames  Per  Second 
[FPS]  or  hertz  [Hz])  within  a  common  field  of  regard.  MI  defines  temporal  domains  of  1  Hz  or  higher, 
and  still  imagery  defines  temporal  domains  of  less  than  1  Hz. 

For  the  purposes  of  the  JTA,  MI  Data  Interchange  Standards  are  divided  into  four  categories: 

□  MI  Systems,  which  create,  transmit,  edit,  store,  archive,  or  disseminate  digital  motion  imagery 
for  real-time,  near-real-time,  or  for  other  end-user  product  distribution,  usually  in  support  of 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  activities. 

□  Video  Teleconference  (VTC)  Systems,  which  provide  real-time  visual  interchange  between 
remote  locations  typically  in  support  of  meetings.  When  VTC  systems  are  used  for  the  display 
of  motion  imagery,  the  standards  in  the  MI  section  apply. 

□  Video  Telemedicine  Systems,  which  provide  real-time  visual  interchange  between  remote 
locations  in  biomedical  applications  including  fiber-optic  and  VTC.  Though  there  are  no  Video 
Telemedicine  standards  specifically  mandated  in  this  section  of  the  JTA,  when  any  Video 
Telemedicine  System  is  used  for  the  purpose  of  motion  imagery  data  dissemination,  the 
standards  mandated  in  this  section  of  the  JTA  apply. 

□  Video  Support  Services,  which  enable  end-user  applications  associated  with  motion  imagery 
(video)-based  training,  news  gathering,  or  other  non-critical  functions  that  do  not  directly 
support  the  warfighter.  This  includes  traditional  studio  and  field  video  productions  not 
associated  with  DoD  warfighter  operations. 

The  standards  and  use  directives  for  each  class  of  motion  imagery  systems  are  noted  in  the  following 
sections: 
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2.5.4.6.1  Motion  Imagery  Systems 

Department  of  Defense  Directive  Number  5 105.60,  1 1  October  1996,  established  the  National  Imagery 
and  Mapping  Agency  (NIMA).  NIMA,  through  the  National  System  for  Geospatial  Intelligence 
(NSGI),  has  the  mission  to  “prescribe  and  mandate  standards  and  end-to-end  technical  architectures 
related  to  imagery,  imagery  intelligence,  and  geospatial  information  for  the  DoD  Components  and  for 
the  non-DoD  elements  of  the  Intelligence  Community”  to  include: 

□  Standards  for  end-to-end  architectures  related  to  imagery,  imagery  intelligence,  and  geospatial 
information. 

□  Technical  guidance  and  direction  to  all  the  DoD  Components  and  the  non-DoD  members  of  the 
Intelligence  Community  regarding  standardization  and  interoperability  of  systems  requiring 
geospatial  information  or  imagery  support  and  for  exploitation  and  dissemination  of  imagery 
and  imagery  intelligence  products  and  geospatial  information. 

2.5.4.6.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2. 5. 4.6. 2  Video  Teleconference  Systems 

VTC  standards  are  specified  in  3.4.2. 

2.5.4.6.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.4.6.3  Video  Support  Services 

Video  support  services  specifies  the  structure  and  data  formats  for  the  production,  exchange, 
transmission,  or  use  of  digital  video  data. 

2.5.4.6.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2. 5.4.7  Audio  Data  Interchange 

Effective  compression  of  audio  data  depends  not  only  upon  data  compression  techniques  but  also  upon 
the  application  of  a  psycho-acoustic  model  that  predicts  which  sounds  humans  arc  likely  to  be  able  to 
hear  or  not  hear  in  given  situations.  The  sounds  selected  for  elimination  depend  on  the  bit  rate  available 
for  streaming  the  audio  data  when  the  file  is  decoded  and  played.  Therefore,  the  best  selection  of  a  file 
format  depends  upon  the  bandwidth  assumed  to  be  available  on  the  platform  that  will  decode  the  file. 

2.5.4. 7.1  Audio  Associated  with  Motion  Imagery 

The  classes  of  audio  in  support  of  motion  imagery  (MI)  have  been  subdivided  into  four  categories: 

□  Audio  for  MI  Systems,  which  create,  transmit,  edit,  store,  archive,  or  disseminate  audio  for 
real-time,  near-real-time,  and  other  end-user  product  distribution,  usually  in  support  of 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  activities. 

□  Audio  for  VTC  Systems,  which  provide  real-time  verbal  interchange  between  remote 
locations,  typically  in  support  of  meetings.  When  VTC  systems  are  used  for  the  display  of 
video  imagery,  the  standards  in  the  Audio  for  Video  Imagery  section  apply.  VTC  standards  are 
specified  in  3.4.2. 

□  Audio  for  Video  Telemedicine  Systems,  which  provide  real-time  visual  interchange  between 
remote  locations  in  support  of  biomedical  applications  including  fiber-optic  and  video 
teleconferencing. 

□  Audio  for  Video  Support  Systems,  which  enable  end-user  applications  associated  with 
video/audio-based  training,  news  gathering,  or  other  non-critical  functions  that  do  not  directly 
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support  the  warfighter.  This  includes  traditional  studio  and  field  productions  not  associated 
with  DoD  warfighting  operations. 

The  standards  and  use  directives  for  each  category  of  audio  application  are  given  in  the  following 
sections. 

2. 5.4. 7. 1.1  Audio  for  Motion  Imagery  Systems 

Audio  for  MI  systems  specifies  data  formats  for  the  exchange  of  the  digital  sound  track  associated  with 
video  in  compressed  and  non-compressed  formats. 

2.5.4.7.1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2. 5.4.7. 1.2  Audio  for  Video  Support  Systems 

Effective  compression  of  audio  data  depends  not  only  upon  data  compression  techniques  but  also  upon 
the  application  of  a  psycho-acoustic  model  that  predicts  which  sounds  humans  are  likely  to  be  able  to 
hear  or  not  hear  in  given  situations.  The  sounds  selected  for  elimination  depend  on  the  bit  rate  available 
for  streaming  the  audio  data  when  the  file  is  decoded  and  played.  Therefore,  the  best  selection  of  a  file 
format  depends  upon  the  bandwidth  assumed  to  be  available  on  the  platform  that  will  decode  the  file. 

2.5.4.7.1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5. 4.7. 2  Voice  Encoder 

This  section  provides  standards  for  audio  for  voice  encoder. 

2.5.4.7.2(a)  Emerging.  The  1.2  Kbps  enhanced  Mixed  Excitation  Linear  Prediction  (MELP)  algorithm 
is  based  upon  MIL-STD-3005  and  is  intended  to  extend  seamless  interoperability  to  bandwidth-limited 
users  (HF  links,  MILSATCOMs,  covert  ops,  etc.),  hence  enabling  end-to-end  security  to  this  user 
community.  MIL-STD-3005  provides  a  common  high  performance  voice  encoding  algorithm  for  use 
across  the  communications  infrastructure  and  will  be  included  in  the  current  MIL-STD-3005  as  an 
annex.  For  processing  voice  data  at  rates  under  2.4  Kbps,  the  following  standard  is  emerging: 

-  Analog-to-Digital  Conversion  of  Voice  by  1200  Bit/Second  Mixed  Excitation  Linear  Prediction 

(MELP). 

2.5.4.8  Data  Interchange  Storage  Media 

This  section  provides  standards  for  Data  Interchange  Storage  Media. 

2.5.4.8(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.4.9  Time-of-Day  Data  Interchange 

This  section  provides  standards  for  time-of-day  data  interchange. 

2.5.4.9(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.4.10  Multimedia  Data  Interchange 

This  section  provides  standards  for  Multimedia  Data  Interchange. 

2.5.4.10(a)  Emerging.  For  on-demand  or  real-time  video  and  audio  streaming,  the  following  standard 
is  emerging: 

-  ISMA  Specification  1 .0:2001 ,  Internet  Streaming  Media  Alliance. 
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2.5.4.11  Calendaring  and  Scheduling 

This  section  identifies  standards  for  interoperability  among  calendaring  and  scheduling  systems  used 
by  Surveillance  and  Reconnaissance  (SR),  IT,  and  other  DoD  Intelligence  systems. 

2.5.4.11(a)  Emerging.  The  following  standard  is  emerging: 

-  C321 ,  Calendaring  and  Scheduling  API  (XCS),  Open  Group  Technical  Standard, 

ISBN’l  -8591 2-076-8,  April  1 995. 

2.5.5  Graphics  Services 

These  services  support  the  creation  and  manipulation  of  graphics. 

2.5.5(a)  Emerging.  For  three-dimensional  graphics  development,  the  following  standard  is  emerging: 

-  OpenGL  Graphics  System:  A  Specification  (Version  1.3)  14  Aug  2001. 

2.5.6  Platform  Communications  Services 

These  services  support  the  distributed  applications  that  require  data  access  and  applications 
interoperability  in  networked  environments.  The  emerging  standards  are  provided  in  Section  3. 

2.5.6(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.7  Operating  System  Services 

These  core  services  are  necessary  to  operate  and  administer  a  computer  platform  and  to  support  the 
operation  of  application  software.  They  include  kernel  operations,  the  shell,  and  utilities.  The  operating 
system  (OS)  controls  access  to  information  and  the  underlying  hardware.  These  services  shall  be 
accessed  by  applications  through  either  the  standard  Portable  Operating  System  Interface  (POSIX),  the 
Linux  Standard  Base  (LSB),  or  the  Win32  APIs. 

When  requiring  real-time  operating  systems,  ISO/IEC  ISP  15287-2:2000,  Information  technology  - 
Standardized  Application  Environment  Profile  -  Part  2:  POSIX  Realtime  Application  Support  (AEP) 
should  be  considered  for  use.  It  has  been  designed  to  satisfy  a  wide  range  of  real-time  system 
requirements  based  upon  the  application  platform’s  size  and  function.  It  identifies  four  real-time 
application  environment  profiles  based  on  the  ISO/IEC  9945-1  series  of  standards.  These  are  Minimal 
Realtime  System  Profile  (PSE51),  Realtime  Controller  System  Profile  (PSE52),  Dedicated  Realtime 
System  Profile  (PSE53),  and  Multi-Purpose  Realtime  System  Profile  (PSE54). 

2.5.7(a)  Emerging.  The  following  POSIX  standards  are  emerging: 

-  ISO/IEC  15287-2:2000,  Information  technology  -  Standardized  Application  Environment 
Profile  -  Part  2:  Posix  Realtime  Application  Support  (AEP). 

-  IEEE  1003.1d:1999,  Standard  for  Information  Technology  -  Portable  Operating  System 
Interface  (POSIX)  Part  1 :  System  Application  Program  Interface  (API)  -  Amendment  d: 
Additional  Realtime  Extensions  [C  Language]. 

-  IEEE  1 003.1  j:2000,  Standard  for  Information  Technology  -  Portable  Operating  System 
Interface  (POSIX)  -  Part  1:  System  Application  Program  Interface  (API)  -  Amendment  j: 
Advanced  Realtime  Extensions  [C  Language]. 

-  P1003.1q,  Draft  Standard  for  Information  Technology  -  Portable  Operating  System  Interface 
(POSIX)  Part  1 :  System  Application  Program  Interface  (API)  -  Amendment  x:  Tracing 

[C  Language],  Draft  8,  April  2000. 
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-  PI  003.21,  Draft  Standard  for  Information  Technology  -  Portable  Operating  System  Interface 
(POSIX)  -  Part  1 :  Realtime  Distributed  Systems  Communication  Application  Program  Interface 
(API)  [Language-Independent],  V3.0,  October  1999. 

-  C808,  Networking  Services  (XNS),  Issue  5.2,  Open  Group  Technical  Standard, 

ISBN-1 -8591 2-241 -8,  January  2000. 

The  Open  Group  (TOG),  IEEE,  and  ISO  consolidated  the  standards  that  make  up 
ISO/IEC  9945-1:1996,  ISO/IEC  9945-2:1993,  IEEE  STD  1003.1,  IEEE  STD  1003.2  and  the 
appropriate  parts  of  the  Single  UNIX  Specification  (SUS).  These  will  be  technically  equivalent  in  all 
respects.  The  new  set  of  specifications  will  form  the  core  of  the  SUS,  Version  3.  The  following  standard 
is  emerging: 

-  The  Single  UNIX  Specification,  Version  3  (SUS  v3),  The  Open  Group. 

2.5.8  Internationalization  Services 

The  internationalization  services  provide  a  set  of  services  and  interfaces  that  allow  a  user  to  define, 
select,  and  change  between  different  culturally  related  application  environments  supported  by  the 
particular  implementation.  These  services  include  character  sets,  data  representation,  cultural 
convention,  and  native-language  support. 

2.5.8(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.9  Security  Services 

These  security  services  assist  in  protecting  information  and  computer  platform  resources.  They  must 
often  be  combined  with  security  procedures,  which  are  beyond  the  scope  of  the  IT  service  areas  to  fully 
meet  security  requirements.  Security  services  include  security  policy,  accountability,  and  assurance. 
(Note:  Security  Service  standards  have  been  consolidated  in  Section  6). 

2.5.9(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.10  System  Management  Services 

These  services  provide  capabilities  to  manage  an  operating  platform  and  its  resources  and  users.  System 
management  services  include  configuration  management,  network  management,  fault  management, 
and  performance  management.  The  JTA  facilitates  interoperability  by  identifying  network  management 
standards.  These  standards  can  be  found  in  3.8. 

2.5.10(a)  Emerging.  The  Distributed  Management  Task  Force  (DMTF)  Common  Information  Model 
(CIM)  is  an  approach  to  the  management  of  systems  and  networks  through  the  interchange  of 
management  information  between  management  systems  and  applications.  For  Windows  based  systems, 
the  following  standards  are  emerging: 

-  Common  Information  Model  (CIM)  Version  2.2,  Distributed  Management  Task  Force,  Inc., 

14  June  1999. 

-  Common  Information  Model  (CIM)  Schema  Version  2.5,  Distributed  Management  Task  Force, 
Inc.,  12  June  2001 . 

-  Desktop  Management  Interface  V2.0s  Specification,  Distributed  Management  Task  Force,  Inc., 
24  June  1998. 

-  Specification  for  the  Representation  of  CIM  in  XML  Version  2.0,  Distributed  Management  Task 
Force,  Inc.,  20  July  1999. 
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-  IETF  RFC  3060,  Policy  Core  Information  Model  6  Version  1  Specification,  Internet  Engineering 
Task  Force,  February  2000. 

-  Specification  for  CIM  Operations  over  FITTP  Version  1 .0,  Distributed  Management  Task  Force, 
Inc.,  11  August  1999. 

2.5.11  Distributed  Computing  Services 

These  services  allow  various  tasks,  operations,  and  information  transfers  to  occur  on  multiple 
physically  or  logically  dispersed  computer  platforms.  These  services  include,  but  are  not  limited  to: 
global  time;  data,  file,  and  name  services;  thread  services;  and  remote -process  services. 

2.5.11.1  Distributed-Object  Computing 

Currently  there  are  a  number  of  competing  middleware  technologies  which  enable  distributed  objects 
to  interoperate.  In  recognizing  that  each  of  these  distributed-object  computing  technologies  has 
strengths  that  differentiate  it  from  the  others,  the  JTA  does  not  mandate  the  use  of  any  single  one. 
However,  in  order  to  ensure  interoperability  among  application  objects  in  heterogeneous  distributed 
environments  or  different  object  models,  the  JTA  mandates  a  requirement  for  interworking  with  the 
Object  Management  Group  (OMG)  Object  Management  Architecture  (OMA).  The  OMA  is  composed 
of  the  Common  Object  Request  Broker  Architecture  (CORBA),  CORBA  services,  and  CORBA 
facilities.  For  COM,  application-level  interworking  results  in  COM  clients  interacting  with  non-COM 
servers  and  non-COM  clients  interacting  with  COM  servers. 

2.5.11 .1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

2.5.12  Environment  Management 

Environment  management  services  integrate  and  manage  the  execution  of  platform  services  for 
particular  applications  and  users.  These  services  are  invoked  via  an  easy-to-use,  high-level  interface 
that  enables  users  and  applications  to  invoke  platform  services  without  having  to  know  the  details  of  the 
technical  environment.  The  environment  management  service  determines  which  platform  service  is 
used  to  satisfy  the  request  and  manages  access  to  it  through  the  API. 

2.5.12.1  Electronic  Records  Management 

This  section  provides  standards  for  Electronic  Records  Management. 

2.5.12.1(a)  Emerging.  DoD  5015.2-STD,  Design  Criteria  Standard  for  Electronic  Records 
Management  Software  Applications,  Sections  2.2.1  through  2.2.11,  provides  a  mandatory  baseline  set 
of  requirements  for  Records  Management  Application  (RMA)  software.  RMA  software  may  be  used  by 
DoD  Components  in  the  implementation  of  records  management  programs.  Each  official  Component 
record  is  defined  by  an  approved  Records  Control  Schedule  (RCS).  If  a  Component  chooses  to  maintain 
official  records  in  an  electronic  form,  those  records  must  be  managed  by  application(s)  consistent  with 
this  standard.  The  following  standard  is  emerging: 

-  DoD-5015.2-STD,  Design  Criteria  Standard  for  Electronic  Records  Management  Software 
Applications,  19  June  2002  (Sections  2.2. 1-2. 2.1 .1  only). 

2.5.12.2  Learning  Technology 

Learning  Technology  standards  provide  for  an  integrated  environment  for  education,  training,  and 
decision  support.  A  growing  number  of  technical  standards  for  this  field  are  in  varying  stages  of 
development. 
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2.5.12.2(a)  Emerging.  The  following  standards  are  being  tracked  as  Learning  Technology  emerging 
standards: 

-  IEEE  1484.1 ,  Standard  for  Information  Technology  -  Education  and  Training  Systems 
Architecture  and  Reference  Model,  LTSA  Draft  9,  2001-11-30. 

-  IEEE  P1484.2,  Standard  for  Information  Technology  -  Learning  Systems  -  Learner  Model, 
PAPI  Learner,  Draft  7,  2000-11-29. 

-  IEEE  1484.11 .1 ,  Draft  Standard  for  Learning  Technology  -  Data  Model  for  Content  to  LMS 
Communications,  2001-03-15. 

-  IEEE  1484.12.1  Draft  Standard  for  Learning  Object  Metadata,  2002-03-04. 

2.5.12.3  Biometric  Technology  Services 

Biometric  technologies  are  intended  to  overlay  or  replace  password  systems  so  that  positive  access 
control  can  be  achieved.  The  Biometric  API  (BioAPI)  Specification  allows  software  applications  to 
communicate  with  a  broad  range  of  biometric  technologies  by  providing  a  high-level  generic  biometric 
authentication  model  that  is  suited  for  any  form  of  biometric  technology.  It  covers  the  basic  functions 
of  Enrollment,  Verification,  and  Identification,  and  includes  a  database  interface  to  allow  a  biometric 
service  provider  (BSP)  to  manage  the  identification  population. 

The  Common  Biometric  Exchange  File  Format  (CBEFF)  defines  a  common  set  of  data  elements 
necessary  to  support  multiple  biometric  technologies  and  promote  interoperability  and  utilization  of 
biometric  data.  CBEFF  describes  the  set  of  required  and  optional  data  fields,  and  also  allows  for  new 
formats  to  be  created. 

2.5.12.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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3.1  Introduction 

Information  Transfer  standards  and  profiles  are  described  in  this  section.  These  standards  promote 
seamless  communications  and  information  transfer  interoperability  for  Department  of  Defense  (DoD) 
systems. 

3.2  Purpose  and  Scope 

This  section  identifies  the  information  transfer  standards  required  for  interoperability  between  DoD 
information  technology  (IT)  systems.  These  standards  support  access  for  end-systems  including  host, 
Video  Teleconferencing  (VTC),  facsimile,  Global  Positioning  System  (GPS),  secondary  imagery 
dissemination,  and  Identification  Friend  or  Foe  (IFF).  Networking  and  internetworking  standards  are 
identified.  Transmission  media  standards  for  Military  Satellite  Communications  (MILSATCOM), 
Synchronous  Optical  Network  (SONET),  and  radio  links  as  well  as  network-  and  systems-management 
standards  for  data  communications  and  telecommunications  arc  identified.  In  addition,  several 
communication  services  include  emerging  technologies  and  standards  that  should  be  monitored  for 
future  extension  of  information  transfer  capabilities.This  section  includes  the  Communications 
Services  depicted  in  Figure  1-3,  DoD  Technical  Reference  Model  (TRM).  Security  standards  are 
addressed  in  Section  6. 

3.3  Background 

The  standards  are  drawn  from  widely  accepted  commercial  standards  that  meet  DoD  requirements. 
Where  necessary  for  interoperability,  profiles  of  commercial  standards  are  used.  Military  standards  are 
mandated  only  when  suitable  commercial  standards  are  not  available.  For  example,  the  JTA  makes  use 
of  the  open-systems  architecture  used  by  the  Internet  and  the  Defense  Information  System  Network 
(DISN). 

This  section  contains  two  versions  of  the  Internet  Protocol  (IP),  IP  Version  4  (IPv4)  and  IP  Version  6 
(IPv6),  and  identifies  the  services  that  will  operate  for  each  IP  version.  For  IPv6  there  are  some  services 
that  may  require  the  use  of  emerging  standards. 

Within  this  section,  system  components  are  categorized  as  end-systems,  networks,  subnetworks,  and 
transmission  media.  Each  component  is  addressed  in  subsequent  paragraphs.  End-systems  (e.g.,  host 
computers,  and  terminals)  (3.4)  generally  execute  applications  on  behalf  of  users  and  share  information 
with  other  end-systems  via  networks.  Networks  (3.5)  may  be  relatively  simple  (e.g.,  point-to-point 
links  or  subnetworks  that  are  homogenous  in  protocol  stacks)  or  have  complex  internal  structures  of 
diverse  subnetworks.  Subnetworks  (345)  are  interconnected  via  routers  which  forward  packets  across 
subnetwork  boundaries.  Routers  are  distinct  from  hosts  in  that  they  are  normally  not  the  destination  of 
data  traffic.  End-systems  and  networks  are  connected  by  transmission  media  (3.1). 

This  section  also  addresses  the  standards  used  to  manage  system  components  (3.8).  Network  and 
systems  management  includes  the  set  of  functions  required  for  controlling,  planning,  allocating, 
deploying,  coordinating,  and  monitoring  the  status  and  resources  of  components. 

3.4  End-Systems  Standards 

This  section  addresses  standards  for  the  following  types  of  end-systems:  host,  VTC,  facsimile,  imagery 
dissemination,  GPS,  and  IFF. 
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3.4.1  Host  Standards 

Hosts  are  computers  that  generally  execute  application  programs  on  behalf  of  users  and  share 
information  with  other  hosts.  Internet  Engineering  Task  Force  (IETF)  Standard  3  is  an  umbrella 
standard  that  references  other  documents  and  corrects  errors  in  some  of  the  referenced  documents. 
IETF  Standard  3  also  adds  additional  discussion  and  guidance  for  implementers.  IETF  Standard  3 
consists  of  Request  for  Comments  (RFC)  1122  and  RFC  1123.  This  pair  of  documents  defines  and 
discusses  the  requirements  for  host  system  implementations  of  the  IP  suite.  RFC  1122  covers  the 
communications  protocol  layers  (i.e.,  link  layer,  IP  layer,  and  transport  layer).  RFC  1123  covers  the 
application  layer  protocols. 

3.4.1. 1  Electronic  Mail 

The  standard  for  official  organizational-messaging  traffic  between  DoD  organizations  is  the  Defense 
Message  System’s  (DMS)  X.400-based  suite  of  military  messaging  standards  defined  in  Allied 
Communications  Publication  (ACP)  123.  The  ACP  123  annexes  contain  standards  profiles  for  the 
definition  of  the  DMS  Business  Class  Messaging  (P772)  capability  and  the  Message  Security  Protocol 
(MSP).  Organizational  messaging  is  considered  a  high-assurance  messaging  service  that  requires 
authentication,  delivery  confirmation,  and  encryption.  See  Section  6  for  security  standards.  Since 
X.400  is  not  an  Internet  standard,  see  3.4.1. 10.3  for  operation  over  IP-based  networks. 

3.4.1.1(a)  Emerging.  For  IPv4  and  IPv6,  the  following  SMTP  standards  are  emerging: 

-  IETF  RFC  2231  MIME  Parameter  Value  and  Encoded  Word  Extensions:  Character  Sets, 
Languages,  and  Continuations,  November  1997. 

-  IETF  RFC  2646,  The  Text/Plain  Format  Parameter,  August  1999. 

-  IETF  RFC  3023,  XML  Media  Types,  January  2001 . 

3.4.1. 2  Directory  Services 

Directory  services  are  basically  pointer  systems,  housed  in  databases  that  store  information  on  how  to 
locate,  archive,  administer,  and  use  a  large  collection  of  data  about  users  and  resources  in  a  networked 
environment. 

3.4.1. 2.1  X.500  Directory  Services 

International  Telecommunications  Union  (ITU)  X.500  provides  directory  services  that  may  be  used  by 
users  or  host  applications  to  locate  other  users  and  resources  on  the  network.  While  it  is  appropriate  for 
all  grades  of  service,  it  must  be  used  for  high-grade  service  where  standards-based  access  control, 
signed  operations,  replication,  paged  results,  and  server-to-server  communication  are  required.  It 
provides  the  security  services  used  by  DMS-compliant  X.400  implementations  and  is  mandated  for  use 
with  DMS.  See  Section  6  for  security  standards.  Since  X.500  is  not  an  Internet  standard,  see  3.4.1.11 
for  operation  over  IP-based  networks. 

3.4.1.2.1(a)  Emerging.  For  IPv4  and  IPv6,  the  following  standard  is  emerging: 

-  ITU-T  X.500,  The  Directory  -  Overview  of  Concepts,  Models,  and  Services  -  Data 
Communication  Networks  Directory,  February  2001 . 

3.4.1. 2.2  Lightweight  Directory  Access  Protocol 

Fightweight  Directory  Access  Protocol  (FDAP)  (Version  2)  is  an  Internet  protocol  for  accessing  online 
directory  services.  It  runs  directly  over  Transmission  Control  Protocol  (TCP).  FDAP  derives  from  the 
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X.500  Directory  Access  Protocol  (DAP).  It  is  appropriate  for  systems  that  need  to  support  a  medium 
grade  of  service  in  which  security  is  not  an  issue,  and  access  is  only  needed  to  a  centralized  server. 

3.4.1.2.2(a)  Emerging.  Lightweight  Directory  Access  Protocol  Version  3(LDAPv3)  supports 
standards-based  authentication,  referrals,  and  all  protocol  elements  of  LDAP  (IETF  RFC  1777).  Other 
features  still  under  development  include  standards-based  access  control,  signed  operations,  replication, 
knowledge  references,  and  paged  results.  For  IPv4  and  IPv6,  the  following  standard  is  emerging: 

-  IETF  RFC  2251 ,  Lightweight  Directory  Access  Protocol  Version  3,  December  1997. 

3.4.1 .2.3  Domain  Name  System 

Domain  Name  System  (DNS)  is  a  hierarchical  host-management  system  that  has  a  distributed  database. 
It  provides  the  look-up  service  of  translating  between  host  names  and  IP  addresses.  DNS  uses 
TCP/User  Datagram  Protocol  (UDP)  as  a  transport  service  when  used  in  conjunction  with  other 
services.  Dynamic  DNS  enables  the  automation  of  DNS  updating  by  introducing  a  new  messaging 
mechanism  to  selectively  insert  or  delete  new  entries  into  or  from  the  DNS  database. 

3.4.1.2.3(a)  Emerging.  For  IPv4  and  IPv6,  the  following  DNS  related  standards  are  emerging: 

-  IETF  RFC  1995,  Incremental  Zone  Transfer  in  DNS,  August  1996. 

-  IETF  RFC  1996,  A  Mechanism  for  Prompt  Notification  of  Zone  Changes  (DNS  NOTIFY), 
August  1996. 

3.4.1. 3  File  Transfer 

Basic  file  transfer  is  accomplished  using  the  File  Transfer  Protocol  (FTP),  which  provides  a  reliable  file 
transfer  service  for  text  or  binary  file.  FTP  uses  TCP  as  a  transport  service. 

3.4.1.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.1 .4  Remote  Terminal 

For  American  Standard  Code  for  Information  Interchange  (ASCII)  text-oriented  remote-terminal 
services,  Telecommunications  Network  (TEFNET)  provides  a  virtual  terminal  capability  that  allows  a 
user  to  “log  on”  to  a  remote  system  as  though  the  user’s  terminal  were  directly  connected  to  the  remote 
system. 

3.4.1.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.1 .5  Network  Time  Synchronization 

Network  Time  Protocol  (NTP)  provides  the  mechanisms  to  synchronize  time  and  coordinate  time 
distribution  in  a  large,  diverse  Internet. 

3.4.1.5(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.1 .6  Bootstrap  Protocol 

Bootstrap  Protocol  (BOOTP)  is  used  to  provide  address  determination  and  bootfile  selection.  It  assigns 
an  IP  address  to  workstations  with  no  IP  address. 

3.4.1.6(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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3.4.1. 7  Configuration  Information  Transfer 

The  Dynamic  Host  Configuration  Protocol  (DHCP)  provides  an  extension  of  BOOTP  to  support  the 
passing  of  configuration  information  to  Internet  hosts.  DHCP  consists  of  two  parts:  a  protocol  for 
delivering  host-specific  configuration  parameters  from  a  DHCP  server  to  a  host,  and  a  mechanism  for 
automatically  allocating  IP  addresses  to  hosts. 

3.4.1.7(a)  Emerging.  For  IPv6,  the  following  standard  is  emerging: 

-  IETF  RFC  3315  Dynamic  Host  Configuration  Protocol  for  IPv6  (DHCPv6),  July  2003. 

3.4.1. 8  Web  Services 

Web  services  provide  the  server  and  client  with  Web  access  features  for  connections  between  browsers 
and  servers. 

3.4.1. 8.1  Hypertext  Transfer  Protocol 

Hypertext  Transfer  Protocol  (HTTP)  is  used  for  search  and  retrieval  within  the  Web.  For  securing 
HTTP,  see  Section  6. 

3.4.1 .8.2  Uniform  Resource  Locator 

A  Uniform  Resource  Identifier  (URI)  is  a  string  identifying  an  abstract  or  physical  resource  on  a 
network.  Uniform  Resource  Locators  (URLs)  are  the  subset  of  URIs  that  identify  resources  via  their 
network  location.  URIs  (particularly  URLs)  arc  used  extensively  on  the  Internet.  RFC  2396  defines  the 
generic  syntax  of  URIs,  while  RFC  1738  defines  the  syntax  for  specific  URL  schemes  (such  as  http: 
and  ftp:). 

3.4.1 .8.2(a)  Emerging.  For  IPv6,  the  following  standard  for  the  syntax  of  URLs,  is  emerging: 

-  IETF  RFC  2732,  Format  for  Literal  IPv6  Addresses  in  URLs,  December  1999. 

3.4.1 .9  Connectionless  Data  Transfer 

The  Connectionless  Data  Transfer  Application  Layer  Standard  allows  Variable  Message  Format  (VMF) 
messages  to  be  used  in  connectionless  applications.  This  standard  uses  User  Datagram  Protocol  (UDP) 
as  a  transport  service. 

3.4.1.9(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.1.10  Transport  Services 

The  transport  services  provide  host-to-host  communications  capabilities  for  application  support 
services.  The  following  sections  define  the  requirements  for  this  service. 

3.4.1.10.1  Transmission  Control  Protocol 

Transmission  Control  Protocol  (TCP)  provides  a  reliable  connection-oriented  transport  service. 
3.4.1.10.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.1.10.2  User  Datagram  Protocol 

User  Datagram  Protocol  (UDP)  provides  an  unacknowledged,  connectionless  datagram  transport 
service. 

3.4.1.10.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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3.4.1.10.3  Open  Systems  Interconnection  Transport  Over  IP-Based  Networks 

This  protocol  provides  the  interworking  between  Transport  Protocol  Class  0  (TPO)  and  TCP  transport 
service  necessary  for  Open  Systems  Interconnection  (OSI)  applications  to  operate  over  IP-based 
networks. 

3.4.1.10.3(a)  Emerging.  For  IPv4  and  IPv6,  the  following  standard  is  emerging: 

-  IETF  RFC  2126,  ISO  Transport  Service  on  Top  of  TCP  (ITOT),  March  1 997. 

3.4.1.11  Network  Services 

Internet  Protocol  (IP)  is  a  basic  connectionless  datagram  service.  All  protocols  within  the  IP  suite  use 
the  IP  datagram  as  the  basic  data  transport  mechanism.  Currently,  IP  Version  4  (IPv4)  is  the  mandated 
internetworking  protocol  for  networks  carrying  operations  traffic  within  DoD.  IPv6  is  the 
next-generation,  network-layer  protocol  of  the  Internet  and  DoD.  IPv6  has  been  designed  to  provide 
better  internetworking  capabilities  than  are  currently  available  within  IPv4.  IPv6  includes  supports  for 
the  following:  expanded  addressing  and  routing  capabilities,  authentication  and  privacy, 
auto-configuration,  and  traffic-class  and  flow-label  fields  to  facilitate  implmentation  of  quality  of 
service  capabilities. 

3.4.1.11(a)  Emerging.  For  IPv6,  the  following  standards  are  emerging: 

-  IETF  RFC  1981  Path  MTU  Discovery  for  IPv6,  August  1996. 

-  IETF  RFC  2473,  Generic  Packet  Tunneling  in  IPv6  Specification,  December  1 998. 

-  IETF  RFC  2710,  Multicast  Listener  Discovery  (MLD)  for  IPv6,  October  1999. 

-  IETF  RFC  3513,  Internet  Protocol  Version  6  (IPv6)  Addressing  Architecture,  April  2003. 

-  IETF  RFC  3587,  IPv6  Global  Unicast  Address  Format,  August  2003. 

Mobile  Host  Protocol  (MHP)  allows  the  transparent  routing  of  IP  datagrams  to  mobile  nodes  in  the 
Internet.  Each  mobile  node  is  always  identified  by  its  home  address,  regardless  of  its  current  point  of 
attachment  to  the  Internet.  For  IPv4,  the  following  standards  are  emerging: 

-  IETF  RFC  2794  Mobile  IP  Network  Access  Identification  Extension  for  IPv4,  March  2000. 

-  IETF  RFC  3344  IP  Mobility  Support  for  IPv4,  August  2002. 

For  IPv4  and  IPv6,  the  following  standard  is  emerging: 

-  IETF  RFC  2507  IP  Header  Compression,  February  1999. 

3.4.1.12  Quality  of  Service 

Quality  of  Service  (QoS)  is  the  ability  of  a  network  to  ensure  that  the  predetermined  traffic  and  service 
requirements  of  a  network  element  (e.g.,  end-system,  router,  or  an  application)  can  be  satisfied. 

3.4.1.12(a)  Emerging.  Resource  ReSerVation  Protocol  (RSVP)  is  used  by  a  host  to  request  specific 
qualities  of  service  from  the  network  for  particular  application  data  streams  or  flows.  See  3.5.4  for 
emerging  Network  QoS  standards.  For  IPv4  and  IPv6,  the  following  receiver-initiated  QoS  standard  is 
emerging: 

-  IETF  RFC  2205,  Resource  ReSerVation  Protocol  RSVP  Version  1  Functional  Specification, 
September  1997. 
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3.4.1.13  Voice  Over  IP 

Voice  over  IP  (VoIP)  refers  to  a  set  of  standards/technologies  that  unite  the  telephony  and  data  worlds 
by  allowing  voice  traffic  to  be  transmitted  over  IP-based  networks.  Two  different  approaches  have  been 
taken  to  bring  voice  to  IP-based  networks.  On  the  one  hand,  the  International  Telecommunication 
Union  (ITU)  has  created  H.323,  a  relatively  complete  and  mature  set  of  standards  that  encapsulate 
Integrated  Services  Digital  Network  (ISDN)  call  signaling  over  an  IP-based  network.  On  the  other 
hand,  the  IETF  has  created  a  set  of  standards  that  perform  similar  functions,  under  the  names  Session 
Initiation  Protocol  (SIP)  and  Media  Gateway  Control  (Megaco).  The  SIP  standard  concerns  simple  call 
placement,  but  is  designed  so  that  its  scope  is  easily  expandable.  Megaco  separates  the  functions 
required  for  interoperability  with  circuit-based  networks.  The  two  different  approaches  both  use  an 
IETF  standard,  RTP  (Real-time  Transport  Protocol),  for  their  voice  channels. 

DoD  systems  should  be  moving  in  the  direction  of  full  convergence  of  traffic  (voice,  video,  data)  on  a 
single  IP  internetwork  as  well  as  seamless  integration  of  multimedia  information  across  fixed  and 
mobile  networks. 

In  light  of  the  fact  that  there  are  currently  two  options  for  VoIP  standards,  it  is  DoD’s  goal  to  select  a 
set  of  mandated  standards  for  this  section  of  the  JTA  by  mid-CY  04. 

3.4.1.13(a)  Emerging.  The  following  VoIP  standards  are  emerging: 

-  ITU-T  Recommendation  H.323,  Packet-Based  Multimedia  Communications  Systems 
(Version  2),  February  1998. 

-  IETF  RFC  3261 ,  Session  Initiation  Protocol,  June  2002. 

-  IETF  RFC  3015,  Megaco  Protocol  Version  1 .0,  November  2000. 

-  IETF  RFC  1889  RTP:  A  Transport  Protocol  for  Real-Time  Applications,  January  1996. 

3.4.1.14  Communication  Protocols  for  High-Stress,  Resource-Constrained  Environments 

DoD  entered  a  cooperative  effort  in  September  1997  with  the  National  Aeronautics  and  Space 
Administration  (NASA)  and  the  National  Security  Agency  (NSA)  to  develop  Internet-based  protocols 
for  “stressed”  communications  links.  Such  links  arc  characterized  by  one  or  more  of  high  bit  error  rates, 
long  delays,  low  bandwidths,  and  high  degrees  of  asymmetry.  This  work  is  also  applicable  for  systems 
with  limited  computer  processing  power. 

3.4.1.14(a)  Emerging.  The  protocol  suite,  called  the  Space  Communications  Protocol  Specification 
(SCPS),  increases  the  reliability  and  speed  of  data  transfer  over  such  links,  increases  interoperability 
with  both  DoD  and  non-DoD  assets,  and  decreases  the  cost  of  operating  our  systems.  This  set  of 
protocols  is  particularly  applicable  to  radio  frequency  Internet  communications  in  battlefield  jamming 
environments.  The  suite  has  been  issued  as  both  Consultative  Committee  for  Space  Data  Systems 
(CCSDS)  and  ISO  standards  (with  the  same  content).  The  suite  consists  of  four  protocols  that  operate 
at  or  above  the  network  layer  of  the  Open  Systems  Interconnect  (OSI)  model — File  Protocol,  Transport 
Protocol,  Security  Protocol,  and  Network  Protocol. 

For  stressed  communications  environments  (such  as  satellite  links)  where  high  bit  error  rates,  long 
delays,  low  bandwidth,  and/or  data  rate  asymmetry  make  the  standard  TCP/IP  suite’s  performance 
unacceptable,  the  following  standards  are  emerging  for  internetworking  and  file  exchange: 

-  CCSDS  713.0-B-1/1SQ  15891 :2000,  Space  data  and  information  transfer  systems  - 
Protocol  specification  for  space  communications  -  Network  protocol,  5  October  2000. 
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-  CCSDS  713.5-B-1/ISO  15892:2000,  Space  data  and  information  transfer  systems  - 
Protocol  specification  for  space  communications  -  Security  protocol,  5  October  2000. 

-  CCSDS  714.0-B-1/ISQ  15893:2000,  Space  data  and  information  transfer  systems  - 
Protocol  specification  for  space  communications  -  Transport  protocol,  5  October  2000. 

-  CCSDS  717.0-B-1/ISQ  15894:2000,  Space  data  and  information  transfer  systems  - 
Protocol  specification  for  space  communications  -  File  protocol,  5  October  2000. 

More  information  is  available  at:  http://www.scps.org  and  http://www.ccsds.org. 

3.4.2  Video  Teleconferencing  Standards 

The  Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and  Intelligence) 
(ASD[C3IJ)  mandated  Federal  Telecommunications  Recommendation  (FTR)  1080B-2002  Video 
Teleconferencing  Profile  (VTCP)  identifies  ITU-T  H.320  and  H.323  as  the  key  standards  to  provide 
interoperability  between  Video  Teleconferencing  (VTC)  terminal  equipment.  ITU-T  H.320,  Narrow 
Band  Visual  Telephone  Systems  and  Terminal  Equipment,  May  1999,  is  an  umbrella  standard  of 
recommendations  addressing  audio,  video,  signaling  and  control  for  digital  circuit  switched  networks 
operating  at  data  rates  of  56-1,920  kilobits  per  second  (kbits/s)  such  as  ISDN.  ITU-T  H.323, 
Packet-based  Multimedia  Communications  Systems,  February  1998,  is  an  umbrella  standard  of 
recommendations  addressing  audio,  video,  signaling  and  control  for  packet-switched  networks.  Also  in 
the  FTR  is  ITU-T  T.120,  Data  Protocols  for  Multimedia  Conferencing,  July  1996,  which  references  a 
family  of  standards  for  applications  implementing  the  features  of  audiographic  conferencing,  facsimile, 
still  image  transfer,  annotation,  pointing,  whiteboard,  file  transfer,  audiovisual  control,  and  application 
sharing. 

3.4.2(a)  Emerging.  For  integrating  packet  and  circuit  switched  networks  for  transmission  of 
multimedia  traffic,  the  following  standards  are  emerging: 

-  ITU-T  H.323,  Packet-based  Multimedia  Communications  Systems,  November  2000.  This 
standard  has  the  most  industry  support  for  VTC  over  ATM. 

The  above  standard  provides  for  two  modes  of  operation  over  ATM:  1)  IP  over  ATM  media  stream  for 
delivery  of  H.225.0  and  H.245  messages  and  for  the  RTCP  portion  of  the  audio  and  video  streams,  and 
2)  Real-Time  Protocol  (RTP)  on  AAL5  for  RTP  audio  and  video  streams.  Implementation  of  H.323 
over  non-LAN  media  (e.g.,  Metropolitan  Area  Networks  [MANs]  and  WANs,  such  as  the  Internet, 
SIPRNET,  JWICS)  is  still  evolving. 

-  ITU-T  H.248,  Gateway  Control  Protocol,  June  2000. 

-  IETF  RFC  3435  Media  Gateway  Control  Protocol  (MGCP)  Version  1 .0,  January  2003. 

-  IETF  RFC  3261 ,  Session  Initiation  Protocol  (SIP),  June  2002. 

For  IP-based,  broadcast-quality  video  rates  of  less  than  1  Mbps,  the  ISO/IEC  MPEG  and  the  ITU-T 
Video  Coding  Expert  Group  (VCEG)  have  joined  efforts  in  the  development  of  the  emerging  H.26L 
standard  which  was  initiated  by  the  ITU-T  committee.  Upon  ratification,  the  new  standard  will  be 
designated  as  ITU-T  H.264  and  MPEG-4  Part  10.  The  following  standard  is  emerging: 

-  ITU-T  H.264/ISO/IEC  FCD  14496-10,  Advanced  Video  Coding,  July  2002. 

3.4.3  Facsimile  Standards 

The  following  facsimile  standards  are  required  for  transmitting  and  receiving  hardcopy  in  analog  and 
digital  forms.  Facsimile  is  the  process  by  which  fixed  graphic  images,  such  as  printed  text  and  pictures, 
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are  scanned,  and  the  information  converted  into  electrical  signals  that  may  be  transmitted  over  a 
telecommunications  system  and  used  to  create  a  copy  or  file  of  the  original.  Facsimile  standards  can  be 
also  employed  for  the  transmission  and  reception  of  facsimile  data  to  or  from  a  computer  without 
requiring  a  hardcopy  at  either  end.  The  following  facsimile  standards  are  required  for  transmitting  and 
receiving  copy  in  analog  and  digital  modes. 

3.4.3. 1  Analog  Facsimile  Standards 

3.4.3.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.3.2  Digital  Facsimile  Standards 

Digital  facsimile  equipment  standards  for  Type  I  and/or  Type  II  modes  are  used  for  digital  facsimile 
terminals  operating  in  tactical,  high  bit  error  rate  (BER)  environments  and  for  facsimile  transmissions 
utilizing  encryption  or  interoperability  with  North  Atlantic  Treaty  Organization  (NATO)  countries. 

3.4.3.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.4  Imagery  Dissemination  Communications  Standards 

The  Tactical  Communications  Protocol  2  (TAC02)  is  the  communications  component  of  the  National 
Imagery  Transmission  Format  Standard  (NITFS)  suite  of  standards  used  to  disseminate  secondary 
imagery.  TAC02  is  used  over  point-to-point  tactical  data  links  in  high-BER  disadvantaged 
communications  environments.  TAC02  is  used  to  transfer  secondary  imagery  and  related  products  in 
which  JTA  transfer  protocols  in  3.4.1.10  fail  (e.g.,  TAC02  only  applies  to  users  having  simplex  and 
half-duplex  links  as  then-  only  means  of  communications).  MIF-HDBK-1300A,  NITFS,  provides 
guidance  to  implement  various  Technical  Interface  Specifications  (TIS)  to  connect  the  TAC02  host  to 
specific  cryptographic  equipment. 

3.4.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.4.5  Global  Positioning  System 

The  CJCS  (CJCSI  6130.01A,  1998  CJCS  Master  Positioning,  Navigation,  and  Timing  Plan)  has 
declared  that  the  GPS  will  be  the  primary  radionavigation  system  source  of  positioning,  navigation  and 
timing  (PNT)  for  DoD.  GPS  is  a  space-based,  worldwide,  precise  positioning,  velocity,  and  timing 
system.  It  provides  an  unlimited  number  of  suitably  equipped  passive  users  with  a  force-enhancing, 
common-grid,  all-weather,  continuous,  three-dimensional  PNT  capability. 

3.4.5(a)  Emerging.  The  GPS  Signal-in-Space  (SIS)  is  being  enhanced  to  accommodate 
next-generation  security  functions.  These  functions  will  significantly  enhance  the  combatant 
commander’s  ability  to  use  the  GPS  PPS  capability  and  other  GPS  sensor  information  in  all 
environments.  These  functions  are  exclusively  supported  by  the  Selective  Availability  Anti-Spoofing 
Module  (SAASM)  architecture.  The  following  standard  is  emerging: 

-  SS-GPS-001  A,  Navstar  GPS  Selective  Availability/Anti-Spoofing  Module  System 
Specification,  27  Sep  99. 

3.4.6  Identification  Friend  or  Foe 

The  primary  function  of  Identification  Friend  or  Foe  (IFF)  is  to  establish  the  identity  of  all  friendly 
systems  within  the  surveillance  volume  of  surface-to-air,  air-to-air,  and  some  air-to-ground  Weapon 
System  platforms.  The  need  for  friend  identification  is  to  permit  tactical  action  against  all  foe 
(non-friendly)  systems  and  to  avoid  tactical  action  against  friendly  systems.  This  need  is  a  key  element 
in  modern  combat,  as  an  object  detected  by  a  sensor,  even  beyond  visual  range,  has  to  be  identified  and 
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classified  as  early  as  possible  so  that,  if  necessary,  either  an  appropriate  defense  can  be  prepared  against 
the  foe  or  that  steps  can  be  taken  to  prevent  the  friend  from  being  engaged/attacked  by  friendly  forces. 

3.4.6(a)  Emerging.  The  following  standard  defines  the  required  characteristics  of  military  IFF  systems 
to  support  the  new  NATO  Mode  5  capabilities: 

-  DoD  AIMS  03-1000  Mark  XI I  A,  Performance/Design  and  Qualification  Requirements  Technical 
Standard  for  the  ATCRBS/IFF/MARK  XIIA  Electronic  Identification  System  and  Military 
Mode  S. 

3.5  Network  Standards 

Networks  are  made  up  of  subnetworks,  and  the  internetworking  (router)  elements  needed  for 
information  transfer.  This  section  identifies  the  standards  needed  to  access  certain  subnetworks  and  for 
routing  and  interoperability  between  the  subnetworks. 

3.5.1  Internetworking  (Router)  Standards 

Routers  are  used  to  interconnect  various  subnetworks  and  end-systems.  Protocols  necessary  to  provide 
this  service  are  specified  below.  IETF  RFC  1812  is  an  umbrella  standard  that  references  other 
documents  and  corrects  errors  in  some  of  the  referenced  documents.  In  addition,  some  of  the  standards 
mandated  for  hosts  in  3.4.1  also  apply  to  routers.  Security  requirements  are  addressed  in  Section  6. 

3.5.1(a)  Emerging.  For  IPv6,  the  following  standard  is  emerging: 

-  IETF  RFC  3315  Dynamic  Host  Configuration  Protocol  for  IPv6  (DHCPv6),  July  2003. 

3.5.2  Internet  Protocol 

IP  is  a  basic  connectionless  datagram  service.  All  protocols  within  the  IP  suite  use  the  IP  datagram  as 
the  basic  data  transport  mechanism.  Currently,  IP  Version  4  (IPv4)  is  the  mandated  internetworking 
protocol  for  networks  carrying  operations  traffic  within  DoD.  IPv6  is  the  next-generation, 
network-layer  protocol  of  the  Internet  and  DoD.  IPv6  has  been  designed  to  provide  better 
internetworking  capabilities  than  are  currently  available  within  IPv4.  IPv6  includes  supports  for  the 
following:  expanded  addressing  and  routing  capabilities,  authentication  and  privacy,  autoconfiguration, 
and  traffic-class  and  flow-label  fields  to  facilitate  implementation  of  quality  of  service  capabilities. 

3.5.2(a)  Emerging.  For  IPv4,  the  following  standards  are  emerging: 

-  IETF  RFC  1981,  path  MTU  Discovery  for  IPv6,  August  1 996. 

-  IETF  RFC  2710  Multicast  Listener  Discovery  (MLD)  for  IPv6,  October  1999. 

-  IETF  RFC  3513,  Internet  Protocol  Version  6  (IPv6)  Addressing  Architecture,  April  2003. 

-  IETF  RFC  3587,  IPv6  Global  Unicast  Address  Format,  August  2003. 

Mobile  Host  Protocol  (MHP)  allows  the  transparent  routing  of  IP  datagrams  to  mobile  nodes  in  the 
Internet.  Each  mobile  node  is  always  identified  by  its  home  address,  regardless  of  its  current  point  of 
attachment  to  the  Internet.  For  IPv4,  the  following  standards  are  emerging: 

-  IETF  RFC  2794  Mobile  IP  Network  Access  Identification  Extension  for  IPv4,  March  2000. 

-  IETF  RFC  3344,  IP  Mobility  Support  for  IPv4,  August  2002. 
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For  IPv4  and  IPv6,  the  following  standard  is  emerging: 

-  IETF  RFC  2507,  IP  Header  Compression,  February  1999. 

3.5.3  Internet  Protocol  Routing 

Routers  exchange  connectivity  information  with  other  routers  to  determine  network  connectivity  and 
adapt  to  changes  in  the  network.  This  enables  routers  to  determine,  on  a  dynamic  basis,  where  to  send 
IP  packets. 

3.5.3. 1  Interior  Routers 

Routers  within  an  autonomous  system  are  considered  local  routers  that  are  administered  and  advertised 
locally  by  means  of  an  interior-gateway  protocol. 

3.5.3.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.5.3.2  Exterior  Routers 

Exterior-gateway  protocols  are  used  to  specify  routes  between  autonomous  systems. 

3.5.3.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.5.4  Network  Quality  of  Service  Standards 

Quality  of  Service  (QoS)  is  the  ability  of  a  network  to  ensure  that  the  predetermined  traffic  and  service 
requirements  of  subnetwork  elements  satisfy  the  end-to-end  interoperability  requirements  of  the 
network. 

3.5.4.1  General  Quality  of  Service  Standards 

To  ensure  interoperability  by  providing  acceptable  quality  of  service  within  DoD  networks. 

3.5.4.1(a)  Emerging.  To  provide  services  over  the  LAN/WAN  beyond  the  current  best-effort  IP-based 
service,  the  following  standard  protocols,  currently  under  development,  to  enable  end-to-end  QoS  are 
emerging  for  IPv4  and  IPv6: 

-  IETF  RFC  2205,  Resource  Reservation  Protocol  (RSVP)  -  Version  1  Functional  Specification, 
September  1997. 

-  IETF  RFC  2207  RSVP  Extensions  for  IPSEC  Data  Flows,  September  1 997. 

-  IETF  RFC  2210  The  Use  of  RSVP  with  IETF  Integrated  Services,  September  1997. 

-  IETF  RFC  2380  RSVP  over  ATM  Implementation  Requirements,  August  1998. 

-  IETF  RFC  2474,  Definition  of  the  Differentiated  Services  Field  (DS  Field)  in  the  IPv4  and 

IPv6  Headers,  December  1998. 

-  IETF  RFC  3031  Multi-protocol  Label  Switching  Architecture,  January  2001. 

-  IETF  RFC  3168  The  Addition  of  Explicit  Congestion  Notification  (ECN)  to  IP,  September  2001 . 

-  IETF  RFC  3175  Aggregation  of  RSVP  for  IPv4  and  IPv6  Reservations,  September  2001 . 

-  IEEE  802.1Q:1998,  IEEE  Standard  for  Local  and  Metropolitan  Area  Networks:  Virtual  Bridge 
Local  Area  Networks. 

-  ISO/I  EC  15802-3:1998  Information  technology  -  Telecommunications  and  information 
exchange  between  systems  -  Local  and  metropolitan  area  networks  -  Common  specifications 
-  Part  3:  Media  Access  Control  (MAC)  Bridges. 
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3.5.4.2  Voice  Quality  of  Service  Standards 

To  ensure  interoperability  by  providing  acceptable  service  quality  between  voice  services  within  the 
Defense  Switched  Network  (DSN). 

3.5.4.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.6  Subnetworks 

This  section  identifies  the  standards  needed  to  access  subnetworks  used  in  joint  environments. 

3.6.1  Local  Area  Network  Access 

While  no  specific  LAN  technology  is  mandated,  the  following  is  required  for  interoperability  in  a  joint 
environment.  This  requires  provision  for  a  LAN  interconnection.  Ethernet,  the  implementation  of 
Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD),  is  the  most  common  LAN 
technology  in  use  with  TCP/IP.  The  hosts  use  a  CSMA/CD  scheme  to  control  access  to  the  transmission 
medium.  An  extension  to  Ethernet,  Fast  Ethernet  provides  interoperable  service  at  both  10  Mbps  and 
100  Mbps.  Higher-speed  interconnections  are  provided  by  100BASE-TX  (two  pair's  of  Category  5 
unshielded  twisted  pair,  with  100BASE-TX  Auto-Negotiation  features  employed  to  permit 
interoperation  with  10BASE-T). 

3.6.1(a)  Emerging.  The  802.11  family  of  standards  provide  a  common  set  of  operational  rules  for 
airwave  interoperability  of  wireless  Local  Area  Network  (LAN)  products  from  different  vendors.  The 
original  IEEE  802.11  standard  was  updated  with  editorial  changes.  The  original  physical  layer  was 
updated  by  IEEE  802.11a  and  IEEE  802.11b.  The  Medium  Access  Control  (MAC)  layer  is  currently 
undergoing  revision  and  will  be  updated  by  IEEE  802. Ilf.  The  following  standards  are  emerging: 

-  I  SO/I  EC  8802-111:1999  (ISO/IEC)  (IEEE  Std  802.11  -  1999)  Information  Technology  - 
Telecommunications  and  information  exchange  between  systems  -  Local  and  metropolitan 
area  networks  -  Specific  requirements  -  Part  1 1 :  Wireless  LAN  Medium  Access  Control  (MAC) 
and  Physical  Layer  (PHY)  Specifications. 

-  IEEE  802.11a-1999,  Supplement  to  Information  technology  -  Telecommunications  and 
information  exchange  between  systems  -  Local  and  metropolitan  area  networks  -  Specific 
requirements  -  Part  11 :  Wireless  LAN  Medium  Access  Control  (MAC)  and  Physical  Layer 
(PHY)  Specifications:  High  Speed  Physical  Layer  (PHY)  in  the  5  GHz  Band. 

-  IEEE  802.11b-1999,  Supplement  to  Information  technology  -  Telecommunications  and 
information  exchange  between  systems  -  Local  and  metropolitan  area  networks  -  Specific 
requirements  -  Part  11 :  Wireless  LAN  Medium  Access  Control  (MAC)  and  Physical  Layer 
(PHY)  Specifications:  Higher  Speed  Physical  Layer  (PHY)  Extension  in  the  2.4  GHz  band. 

For  using  IPv6  over  Joint  Task  Force  ethernet  LANs,  the  following  standard  is  emerging: 

-  IETF  RFC  2464  Transmission  of  IPv6  Packets  over  Ethernet  Networks,  December  1998. 

3.6.2  Point-to-Point  Standards 

The  point-to-point  standards  are  designed  for  single  links  that  transport  packets  between  two  peers. 
These  links  provide  full-duplex,  simultaneous,  bi-directional  operation,  and  are  assumed  to  deliver 
packets  in  order. 

3.6.2(a)  Emerging.  PPP  Multilink  Protocol,  allows  for  aggregation  of  bandwidth  via  multiple 
simultaneous  dial-up  connections.  It  proposes  a  method  for  splitting,  recombining,  and  sequencing 
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datagrams  across  multiple  PPP  links  connecting  two  systems.  For  IPv4,  the  following  standards  are 
emerging: 

-  IETF  RFC  1990,  The  PPP  Multilink  Protocol,  August  1996. 

-  IETF  RFC  3241  Robust  Fleader  Compression  (ROFIC)  over  PPP,  April  2002. 

For  IPv6,  the  following  standards  are  emerging: 

-  IETF  RFC  2472,  IP  Version  6  over  PPP,  December  1998. 

-  IETF  RFC  3241  Robust  Header  Compression  (ROHC)  over  PPP,  April  2002. 

3.6.3  Combat  Net  Radio  Networking 

Combat  Net  Radios  (CNRs)  are  a  family  of  radios  that  allow  voice  or  data  communications  for  mobile 
users.  These  radios  provide  a  half-duplex,  broadcast-transmission  media  with  potentially  high  BERs. 
The  method  by  which  IP  packets  are  encapsulated  and  transmitted  is  specified  in  MIL-STD-188-220C. 

3.6.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.6.4  Integrated  Services  Digital  Network 

Integrated  Services  Digital  Network  (ISDN)  is  an  international  standard  used  to  support  integrated 
voice  and  data  over  standard,  twisted-pair  wire.  ISDN  defines  a  Basic  Rate  Interface  (BRI)  and  Primary 
Rate  Interface  (PRI)  to  provide  digital  access  to  ISDN  networks.  These  interfaces  support  both  circuit- 
and  packet-switched  services.  It  should  be  noted  that  deployable  systems  might  additionally  be  required 
to  support  other  non-North  American  ISDN  standards  when  accessing  region-specific  international 
infrastructure  for  ISDN  services.  The  JTA  recognizes  that  this  is  a  critical  area  affecting  interoperability 
but  does  not  recommend  specific  solutions  in  this  version. 

3.6.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.6.5  Asynchronous  Transfer  Mode 

Asynchronous  Transfer  Mode  (ATM)  is  a  high-speed,  switched-data  transport  technology  that  takes 
advantage  of  primarily  low  BER  transmission  media  to  accommodate  intelligent  multiplexing  of  voice, 
data,  video,  and  composite  inputs  over  high-speed  trunks  and  dedicated,  user  links.  ATM  is  a  layered 
type  of  transfer  protocol  with  the  individual  layers  consisting  of  an  ATM  Adaptation  Layer  (AAL),  the 
ATM  layer,  and  the  Physical  Layer. 

3.6.5(a)  Emerging.  ATM  Conformance  Testing,  the  ATM  Forum’s  conformance  test  suites.  Protocol 
Information  Conformance  Statement  (PICS)  pro  forma,  and  the  Protocol  Implementation  Extra 
Information  for  Testing  (Pixit)  pro  forma  are  available  to  demonstrate  interoperability  between  vendor 
products. 

-  ATM  Forum,  af-aic-01 78.000,  ATM-Multiprotocol  Label  Switching  (MPLS)  Network 
Interworking  Version  1 .0,  August  2001 . 

-  ATM  Forum,  af-tm-0121 .000,  Traffic  Management  Specification  Version  4.1,  March  1999. 

-  ATM  Forum,  af-sig-0076.000,  Addendum  to  UNI  Signalling  V4.0  for  ABR  parameter 
negotiation,  January  1997. 

-  ATM  Forum,  af-mpoa-01 14.000,  Multi-Protocol  Over  ATM  Version  1.1,  May  1999. 

-  ATM  Forum,  af-vtoa-01 13.000,  ATM  Trunking  Using  AAL2  for  Narrowband  Services, 

February  1999. 
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-  ATM  Forum,  af-phy-0086.001,  Inverse  Multiplexing  for  ATM  (IMA)  Specification  Version  1.1, 
March  1999. 

-  ATM  Forum,  af-saa-01 24.000,  Gateway  for  H.323  Media  Transport  Over  ATM,  July  1 999. 

-  ATM  Forum,  af-vtoa-01 19.000,  Low  Speed  Circuit  Emulation  Service  (LSCES),  May  1999. 

-  ATM  Forum,  af-lane-01 12.000,  LAN  Emulation  Over  ATM  Version  2  -  LNNI  Specification, 
February  1999. 

-  ATM  Forum,  af-ra-01 23.000,  PNNI  Addendum  for  Mobility  Extensions,  Version  1 .0,  May  1 999. 

-  ATM  Forum,  af-sec-0096.000,  ATM  Security  Framework  Specification  Version  1 .0, 

February  1998. 

-  TIA/EIA/IS-787,  Common  ATM  Satellite  Interface  Interoperability  Specification  (CASI), 

July  1999. 

3.6.6  Gigabit  Ethernet 

Gigabit  Ethernet  extends  the  speed  of  the  Ethernet  specification  to  1  Gbps.  Gigabit  Ethernet  is  used  for 
campus  networks  and  building  backbones. 

3.6.6(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.6.7  Mobile  Cellular 

Currently  fielded  Second  Generation  (2G)  Personal  Communications  Service  (PCS)  wireless  systems 
will  eventually  be  replaced  by  Third  Generation  (3G)  wireless/cellular  systems,  which  are  currently 
being  developed  in  North  America,  Europe,  and  in  various  Asian  countries.  The  umbrella  standard  for 
3G  is  the  ITU  IMT-2000  family  of  standards.  The  complete  set  of  3G  Radio  interface  specifications  for 
both  Time  Division  Multiple  Access  (TDMA)  and  Code  Division  Multiple  Access  (CDMA)  is 
contained  in  Recommendation  ITU-R  M.  1457- 1  (also  called  IMT.RSPC).  3G  systems  need  to  meet  the 
requirement  of  supporting  data  transmission  at  144  kb/s  for  the  vehicular  user,  384  kb/s  for  the 
dismounted  and  outdoor-to-indoor  user,  and  2  Mb/s  for  the  indoor  office  user.  The  major  issues  that  are 
being  resolved  include  support  for  legacy  cellular  systems  and  mutually  agreed  upon  cellular  standards 
that  permit  global  roaming.  The  standards  associated  with  the  groups  devoted  to  developing  and 
updating  3G  and  the  Recommendation  ITU-R  M.  1457-1  are  the  following:  (1)  The  3rd  Generation 
Partnership  Project  (3GPP),  which  is  focused  on  3G  extensions  of  the  European  GSM  system  and 
interoperability  of  North  American  TDMA  (IS- 1 36)  and  the  3G  follow-on,  UWC-136,  (known  in  ITU 
as  TDMA  Single-Carrier  [SC])  with  GSM  and  UMTS.  The  3GPP  standards  encompass  GSM  and 
GSM-MAP  based  Wideband  CDMA  (WCDMA)  (known  in  ITU  as  CDMA  Direct  Spread  [DS]).  It  is 
also  known  as  the  Universal  Mobile  Telecommunications  System  (UMTS)  and  is  a  part  of  the  ITU 
IMT-2000  concept.  (2)  The  Third  Generation  Partnership  Project  2  (3GPP2)  is  a  collaborative  third 
generation  (3G)  telecommunications  standards-setting  project  comprised  of  North  American  and  Asian 
interests  developing  global  specifications  for  interface  to  ANSI/TIA/EIA-41.  The  3GPP2  is  focused  on 
the  3G  extension  of  the  cdmaOne  (North  American)  CDMA  standard,  and  is  one  of  the  initiatives  of  the 
ITU  IMT-2000  concept.  3GPP2  data  standards  (cdma2000,  known  in  ITU  as  CDMA  Multi-Carrier 
[MC])  are  based  upon  IS-95B.  IS-95B  is  the  packet  mode  version  of  direct  sequence  CDMA  standard 
IS-95A.  3GPP2  uses  existing  work  in  the  Internet  Engineering  Task  Force  (IETF)  on  mobile  IP  to 
enhance  network  architecture.  The  Web  sites  for  these  two  projects  are: 
http://www.3gpp.org  and  http://www.3gpp2.org. 

3.6.7(a)  Emerging.  The  following  3G  Radio  interface  specification  that  contains  both  3GPP  and 
3GPP2  developed  standards  is  emerging: 

-  ITU-R  M. 1457-1 ,  Detailed  Specifications  of  the  Radio  Interfaces  of  IMT-2000,  February  2001 . 
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3.7  Transmission  Media 

Transmission  media  is  used  to  transmit  information  from  one  location  to  another  location.  This  section 
addresses  the  following  types  of  transmission  media:  military  satellite  communications,  radio 
communications,  and  synchronous  optical  network  transmission. 

3.7.1  Military  Satellite  Communications 

Military  Satellite  Communications  (MILSATCOM)  systems  include  those  systems  owned  or  leased 
and  operated  by  DoD  and  those  commercial  satellite  communications  (SATCOM)  services  used  by 
DoD.  The  basic  elements  of  satellite  communications  are  a  space  segment,  a  control  segment,  and  a 
terminal  segment  (air,  ship,  ground,  etc.).  An  implementation  of  a  typical  satellite  link  will  require  the 
use  of  satellite  terminals,  a  user  communications  extension,  and  military  or  commercial  satellite 
resources. 

3.7. 1.1  Ultra-High  Frequency  Satellite  Terminal  Standards 

The  Ultra-High  Frequency  (UHF)  SATCOM  system  operates  on  the  high-VHF  and  low-UHF 
frequencies  (Uplink  292  to  319  MHz;  Downlink  243  to  270  Mhz).  These  relatively  low-frequency 
bands  are  used  for  supporting  many  long-haul  tactical,  contingency,  and  special  military  operations. 
This  section  includes  the  standards  that  define  the  interoperability  and  performance  requirements  for 
user  terminals  and  access  controllers  that  operate  over  the  military  UHF  SATCOM  system.  UHF 
Satellite  Terminal  Standards  define  the  waveforms  and  protocols  to  allow  user  communications  over 
unprocessed  transponders  on  Fleet  SATCOM  (FLTSAT)  and  UHF  Follow-on  (UFO)  satellites. 

3.7.1.1(a)  Emerging.  The  UHF  SATCOM  standards  are  undergoing  a  major  revision  and  will  be 
superseded  by  these  emerging  standards  when  they  are  approved.  The  emerging  standards  are  being 
developed  in  a  layered  type  structure  following  the  ISO/OSI  model.  The  new  standards  will  eliminate 
the  functional  duplicity  of  the  present  standards  and  will  make  them  easier  and  less  expensive  to 
implement.  The  following  standards  are  emerging: 

-  M1L-STD-188-182B,  Interoperability  and  Performance  Standard  for  UHF  SATCOM  DAMA 
Orderwire  Messages  and  Protocols. 

-  MIL-STD-188-183B,  Interoperability  and  Performance  Standard  for  Multiple  Accessing  5-kHz 
and  25-kHz  UHF  SATCOM  Channels. 

-  MIL-STD-188-184A,  Interoperability  and  Performance  Standard  for  the  Data  Control 
Waveform. 

3.7.1 .2  Super-High  Frequency  Satellite  Terminal  Standards 

The  military,  Super-High  Frequency  (SHF)  SATCOM  system  operates  on  the  X-Band 

(7.25  to  8.4  GHz)  of  the  SHF  spectrum.  In  addition,  the  DoD  uses  commercial  SATCOM  systems  that 

operate  on  the  C-Band  (3.4  to  6.65  GHz)  and  Ku-Band  (10.95  to  14.5  GHz)  of  the  SHF  spectrum.  This 

section  includes  the  standards  that  define  the  interoperability  and  performance  requirements  for  user 

terminals  and  access  controllers  that  will  operate  over  military  and  commercial  SHF  SATCOM 

systems. 

3.7.1.2(a)  Emerging.  The  following  draft  standards  are  emerging. 

-  MIL-STD-188-166,  Interface  Standard,  Interoperability  and  Performance  Standard  for  SHF 
SATCOM  Link  Control. 

-  MIL-STD-188-167,  Interface  Standard,  Message  Format  for  SHF  SATCOM  Link  Control. 
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-  MIL-STD-188-170,  Interoperability  and  Performance  Standard  for  SHF  Satellite 
Communications  Anti-Jamming  Modems  (This  modem  uses  spread  spectrum  techniques  to 
protect  SHF  SATCOM  user  communications  and  control  links  against  enemy  jamming). 

3.7.1. 3  Extremely  High  Frequency  Satellite  Payload  and  Terminal  Standards 

This  section  covers  standards  that  ensure  interoperability  between  satellite  communications  systems 
providing  jam-resistant,  secure  communications  on  the  high-SHF  and  low,  Extremely-High  Frequency 
(EHF)  frequencies  (20  GHz  and  44  GHz)  for  both  low  data  rates  (LDR)  and  medium  data  rates  (MDR). 

3.7.1.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.7.2  Satellite  State-of-Health  Communication  Standards 

National  Space  Policy  directed  DoD  to  lead  U.S.  Government  efforts  to  improve  satellite  operations 
interoperability  among  U.S.  Government  agencies.  The  National  Security  Space  Architect’s  Satellite 
Operations  Architecture  Team  recommended  a  common  set  of  standards  for  LDR  satellite  telemetry 
and  commanding.  These  standards  will  allow  DoD  to  share  health  and  status  resources  with  other 
U.S.  Government  agencies  and  with  allies  to  enhance  satellite  operations  while  limiting  costs.  The 
standards  provide  a  baseline  for  LDR  communication  of  health  and  status  information  between  a 
spacecraft  and  the  ground.  These  standards  are  mandated  for  S-band  communication,  but  may  be 
applied  more  generally. 

3.7.2(a)  Emerging.  For  transmission  of  telemetry,  command,  and  control  and  status  data  over  IP-based 
ground  networks,  the  following  standards  are  emerging: 

-  ISO  15396:1998  (CCSDS  91 0.4-B-1 )  Space  Data  and  Information  Transfer  Systems  -  Cross 
Support  Reference  Model  -  Space  Link  Extension  Services. 

-  CCSDS  910.5-R-2,  Space  Link  Extension  -  Service  Management  Specification, 

September  2001 . 

-  CCSDS  910.7-R-1 ,  Space  Link  Extension  -  Service  Management  -  Space  Link  Physical  Layer 
Management  Object  Specification,  October  2001 . 

-  CCSDS  911.1-R-2,  Space  Link  Extension  -  Return  All  Frames  Service  Specification, 
November  2000. 

-  CCSDS  911 ,2-R-l ,  Space  Link  Extension  -  Return  Virtual  Channel  Frames  Service 
Specification,  November  1997. 

-  CCSDS  912.1-R-2,  Space  Link  Extension  -  Forward  CLTU  Service  Specification,  May  2000. 

-  CCSDS  912.3-R-1 ,  Space  Link  Extension  -  Forward  Packet  Service  Specification, 

November  1997. 

3.7.3  Radio  Communications 

The  following  services  are  required  for  the  transmission  and  reception  of  radio  signals. 

3.7.3(a)  Emerging.  For  anti-jamming  capabilities  for  VHF  radio  systems: 

-  MIL-STD-1 88-241 ,  RF  Interface  Requirements  for  VHF  Frequency  Hopping  Tactical  Radio 
Systems. 

3.7.3. 1  Tactical  Data  Link  Transmission  Standards 

Tactical  data  links  consist  of  data  elements,  standard  message  formats,  protocols  for  exchanging  the 
messages,  and  the  transmission  waveform. 
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3.7.3.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.7.4  Synchronous  Optical  Network  Transmission  Facilities 

Synchronous  Optical  Network  (SONET)  is  a  telecommunications  transmission  standard  for  use  over 
fiberoptic  cable.  SONET  is  the  North  American  subset  of  the  ITU  standardized  interfaces,  and  includes 
a  hierarchical,  multiple-structure,  optical-parameters,  and  service  mapping. 

3.7.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

3.8  Network  and  Systems  Management 

Network  and  Systems  Management  (NSM)  provides  the  capability  to  manage  designated  networks, 
systems,  and  information  services.  This  includes:  controlling  the  network’s  topology;  dynamically 
segmenting  the  network  into  multiple  logical  domains;  maintaining  network  routing  tables;  monitoring 
the  network  load;  and  making  routing  adjustments  to  optimize  throughput.  NSM  also  provides  the 
capability  to  review  and  publish  addresses  of  network  and  system  objects;  monitor  the  status  of  objects; 
start,  restart,  reconfigure,  or  terminate  network  or  system  services;  and  detect  loss  of  network  or  system 
objects  in  order  to  support  automated  fault  recovery.  A  management  system  has  four  essential 
elements — management  stations;  management  agents;  management  information  bases  (MIBs);  and 
management  protocols — to  which  these  standards  apply. 

3.8.1  Data  Communications  Management 

Data  communications  management  stations  and  management  agents  (in  end-systems  and  networked 
elements)  shall  support  the  Simple  Network  Management  Protocol  (SNMP). 

3.8.1(a)  Emerging.  The  SNMPv3  Management  Framework  is  described  in  IETF-Proposed  Standard 
RFCs  257 1  through  2575.  SNMPv3  builds  on  the  mandate  SNMPV1,  IETF  Standard  15,  and  addresses 
the  deficiencies  in  SNMPv2  relating  to  security  (e.g.,  authentication  and  privacy)  and  administration 
(e.g.,  naming  of  entities,  usernames  and  key  management,  and  proxy  relationships).  Implementations  of 
the  RFCs  are  undergoing  interoperability  tests  as  part  of  the  process  to  advance  these  specifications 
from  Proposed  to  Draft  state.  The  following  standards  are  emerging: 

-  IETF  RFC  2571  An  Architecture  for  Describing  SNMP  Management  Frameworks,  April  1999. 

-  IETF  RFC  2572,  Message  Processing  and  Dispatching  for  the  Simple  Network  Management 
Protocol  (SNMP),  April  1999. 

-  IETF  RFC  2573  SNMP  Applications,  April  1999. 

-  IETF  RFC  2574  User-based  Security  Model  (USM)  for  version  3  of  the  Simple  Network 
Management  Protocol  (SNMPv3),  April  1999. 

-  IETF  RFC  2575,  View-based  Access  Control  Model  (VACM)  for  the  Simple  Network 
Management  Protocol  (SNMP),  April  1999. 

The  following  SNMP  MIB  modules  are  identified  as  emerging  IETF  standards  for  implementation 
within  systems  that  manage  data  communications  networks: 

-  IETF  RFC  1471  Definitions  of  Managed  Objects  for  the  Link  Control  Protocol  of  the 
Point-to-Point  Protocol,  June  1993. 

-  IETF  RFC  1472,  Definitions  of  Managed  Objects  for  the  Security  Protocol  of  the  Point-to-Point 
Protocol,  June  1993. 

-  IETF  RFC  1473.  Definitions  of  Managed  Objects  for  the  IP  Network  Control  Protocol  of  the 
Point-to-Point  Protocol,  June  1993. 
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-  IETF  RFC  1474,  Definitions  of  Managed  Objects  for  the  Bridge  Network  Control  Protocol  of  the 
Point-to-Point  Protocol,  June  1993. 

-  IETF  RFC  1611  DNS  Server  MIB  Extensions,  May  1994. 

-  IETF  RFC  1612,  DNS  Resolver  MIB  Extensions,  May  1994. 

-  IETF  RFC  1657,  Definitions  of  Management  Objects  for  the  Fourth  Version  of  the  Border 
Gateway  Protocol  (BGP-4)  using  SMIv2,  July  1994. 

-  IETF  RFC  2006,  Definitions  of  Managed  Objects  for  IP  Mobility  Support  using  SMIv2, 

October  1996. 

-  IETF  RFC  2011 ,  SNMPv2  Management  Information  Base  for  the  Internet  Protocol,  using 
SMIv2,  November  1996. 

-  IETF  RFC  2012,  SNMPv2  Management  Information  Base  for  the  Transmission  Control 
Protocol  (TCP),  using  SMIv2,  November  1996. 

-  IETF  RFC  2013  SNMPv2  Management  Information  Base  for  the  User  Datagram  Protocol 
(UDP)  using  SMIv2,  November  1996. 

-  IETF  RFC  2021 ,  Remote  Network  Monitoring  Management  Information  Base  Version  2  using 
SMIv2,  January  1997. 

-  IETF  RFC  2788,  Network  Services  Monitoring  MIB,  March  2000. 

-  IETF  RFC  2789  Mail  Monitoring  MIB,  March  2000. 

-  IETF  RFC  2515,  Definitions  of  Managed  Objects  for  ATM  Management,  February  1999. 

-  IETF  RFC  2605,  Directory  Server  Monitoring  MIB,  June  1999. 

3.9  Telecommunications  Management 

Telecommunications  management  systems  for  telecommunications  switches  will  implement  the 
Telecommunications  Management  Network  (TMN)  framework  to  perform  the  exchange  of  information 
within  a  telecommunications  network. 

3.9(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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4.1  Introduction 

This  section  of  the  Joint  Technical  Architecture  (JTA)  Core  specifies  standards  for  information 
modeling  (i.e.,  activity,  data,  and  object  models)  and  information  exchange  (i.e.,  bit-oriented  and 
character-based  formatted  messages). 

4.2  Purpose 

This  section  specifies  the  minimum  information  modeling,  metadata,  and  information  exchange 
standards  the  Department  of  Defense  (DoD)  will  use  to  develop  or  upgrade  integrated,  interoperable 
systems. 

4.3  Scope  (Applicability) 

The  Information  Modeling  section  applies  to  activity  models,  data  models,  object  models,  and  data 
definitions  used  to  define  physical  databases.  Information  Exchange  Standards  refer  to  the  exchange  of 
information  among  mission-area  applications  within  the  same  system  or  among  different  systems. 

Information  exchange  standards  include  the  Tactical  Data  Links  (TDLs),  bit-oriented  and 
character-based  formatted  messages.  Among  them  arc  the  Tactical  Digital  Information  Links  (TADILs) 
and  United  States  Message  Text  Lormat  (USMTL).  The  goal  of  these  formatted  messages  is  to  provide 
a  timely,  integrated,  and  coherent  picture  for  joint  commanders  and  their  operational  forces. 

4.4  Background 

An  information  model  is  a  representation  at  one  or  more  levels  of  abstraction  of  a  set  of  real-world 
activities,  products,  and/or  interfaces.  Within  the  Information  System  (IS)  domain,  there  are  three  basic 
types  of  models  frequently  created:  activity,  data,  and  object. 

Activity  models  arc  representations  of  mission-area  applications,  composed  of  one  or  more  related 
activities.  The  primary  product  of  each  activity  model  is  the  definition  of  a  measurable  set  of  products, 
services,  and  information  required  to  support  the  mission-area  function. 

Data  models  define  entities,  their  data  elements,  and  illustrate  the  interrelationships  among  the  entities. 
A  data  model  identifies  logical  information  requirements  and  metadata,  applicable  to  persistently  stored 
data,  which  form  a  basis  for  physical  database  schemata  and  standard  data  elements  within  a  relational 
database. 

Object  models  define  the  combined  information  and  process  requirements  within  a  domain  needed  to 
accomplish  a  particular  capability  or  set  of  capabilities,  for  example,  as  defined  by  activity  models. 
Such  models  form  the  basis  of  object-oriented  system  implementations.  They  also  model  system 
interoperability  by  combining  the  metadata  for  shared  data  with  the  allowable  interfaces  for  sharing  that 
data.  Object  models  show  associations  and  dependencies  between  system  interfaces  and  the  essential 
business  rules  for  exercising  those  relationships. 

Efficient  execution  of  information  exchange  requirements  (IERs)  is  key  to  evolving  DoD  toward  the 
goal  of  seamless  information  exchange.  The  primary  component  of  this  infrastructure  is  the  Tactical 
Data  Link  (TDL),  composed  of  message  elements/messages  and  physical  media.  No  single  data  link  is 
applicable  to  every  platform  and  weapon  system.  Tactical  Digital  Information  Links  (TADILs), 
structured  on  bit-oriented  message  standards,  evolved  to  meet  critical  real-time  and  near-real-time 
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message  requirements.  The  USMTF,  designed  primarily  for  non-real-time  exchange,  is  based  on  a 
character-oriented  message  format  and  is  the  standard  for  human-readable  and  machine-processable 
information  exchange. 

4.5  Information  Modeling 

This  section  addresses  standards  for  three  basic  types  of  models  frequently  created:  activity,  data,  and 
object. 

4.5.1  Activity  Model 

Activity  models  are  used  to  document/model  the  activities,  processes,  and  data  flows  supporting  the 
requirements  of  process  improvement  and  system  development  activities.  Prior  to  system  development 
or  major  system  update,  an  activity  model  is  prepared  to  depict  the  mission-area  function  to  a  level  of 
detail  sufficient  to  identify  each  entity  in  the  data  model  that  is  involved  in  an  activity.  The  activity 
model  can  form  the  basis  for  data-  and/or  object-model  development  or  refinement.  It  is  validated 
against  the  requirements  and  doctrine  and  approved  by  the  operational  sponsor. 

4.5.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

4.5.2  Data  Model 

Relational  data  models  are  used  in  software  requirements  analyses  and  design  activities  as  a  logical 
basis  for  physical  data  exchange  and  shared  data  structures  that  can  benefit  from  a  relational  schema 
definition,  including  message  formats  and  schema  for  shared  databases.  Object-oriented  systems  use 
data  models  to  design  relational  data  structures  when  there  is  a  requirement  to  maintain  persistent  data 
storage  for  that  system  in  a  relational  database. 

4.5.2(a)  Emerging.  IDEF1X97  is  being  developed  by  the  IEEE  IDEF1X  Standards  Working  group  of 
the  IEEE  1320.2  Standards  Committee.  The  standard  describes  two  styles  of  the  IDEF1X  model.  The 
key-style  is  used  to  produce  information  models  that  represent  the  structure  and  semantics  of  data 
within  an  enterprise  and  is  backward-compatible  with  the  U.S.  Government’s  Federal  Standard  for 
IDEF1X,  FIPS  PUB  184.  The  identity-style  is  a  wholly  new  language  that  provides  system  designers 
and  developers  with  a  robust  set  of  modeling  capabilities  covering  all  static  and  many  dynamic  aspects 
of  the  emerging  object  model.  This  identity-style  can,  with  suitable  automation  support,  be  used  to 
develop  a  model  that  is  an  executable  prototype  of  the  target  object-oriented  system.  The  identity-style 
can  be  used  in  conjunction  with  emerging  dynamic  modeling  techniques  to  produce  full  object-oriented 
models.  The  following  data  modeling  standard  is  emerging: 

-  IEEE  1320.2:1998,  IEEE  Standard  Conceptual  Modeling  Language-Syntax  and  Semantics  for 
IDEF1X97(IDEF  object). 

4.5.3  Object  Modeling 

Object-oriented  modeling  techniques  are  used  in  the  specification  and  development  of  object-oriented 
systems  and  to  model  and  design  the  interoperability  requirements  of  distributed  components. 

4.5.3(a)  Emerging.  The  XML  Metadata  Interchange  (XMI)  standard  describes  an  information 
interchange  model.  This  model  allows  developers  using  UML  object  technology  tools  to  exchange 
programming  data  in  a  common  format  by  defining  a  set  of  XML  Document  Type  Definitions  (DTDs) 
for  exchanging  UML  information.  The  following  object  modeling  standards  are  emerging: 

-  XML  Metadata  Interchange  (XMI).  Version  1.1,  ad/99-10-22,  25  October  1999. 

-  XML  Metadata  Interchange  (XMI),  Version  1.1-  Appendices,  ad/99-1 0-1 3,  25  October  1 999. 
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4.6  DoD  Data  Architecture  Implementation 

Implementation  of  the  DoD  Data  Architecture  (DDA)  will  be  interpreted  to  mean  that  it  will  serve  as 
the  logical  reference  model  database  schema  defining  the  names,  representations,  and  generalized 
relations  of  data  within  DoD  systems. 

4.7  Data  Definitions 

4.7(a)  Emerging.  ISO/IEC  11179  describes  the  standardization  and  registering  of  data  elements  to 
make  data  understandable  and  shareable.  Data  element  standardization  and  registration  as  described  in 
ISO/IEC  11179  allow  the  creation  of  a  shared  data  environment  in  much  less  time  and  with  less  effort 
than  it  takes  for  conventional  data  management  methodologies.  If  ISO/IEC  11179  is  ever  adopted  as  a 
mandated  standard  it  will  be  necessary  for  it  to  be  fully  harmonized  with  DoD  8320.1-M-l.  The 
following  standard  is  emerging: 

-  ISO/IEC  11179,  Part  3  (DRAFT),  Basic  attributes  of  data  elements,  19  October  2001 . 

4.8  Information  Exchange  Standards 

Information  Exchange  Standards  refer  to  the  exchange  of  information  among  mission-area  applications 
within  the  same  system  or  among  different  systems.  The  scope  of  information  exchange  standards 
follows: 

□  The  exchange  of  information  among  applications  using  shared  databases  or  formatted  message 
structures  shall  be  based  on  the  logical  data  models  developed  from  identifying  information 
requirements  through  activity  models,  where  appropriate.  The  data  model  identifies  the  logical 
information  requirements  that  shall  be  developed  into  physical  database  schemata  and  standard 
data  elements. 

□  The  standard  data  elements  shall  be  exchanged  using  the  data  management,  data  interchange, 
and  distributed  computing  services  of  application  platforms.  (Refer  to  Section  2  for  further 
guidance  on  these  services.)  The  goal  is  to  exchange  information  directly  between  information 
systems  subject  to  security  classification  considerations. 

□  Information  exchange  between  systems  using  object-oriented  interface  definitions  can  be  based 
on  object  models  depicting  those  interfaces  and  the  functional  dependency  of  those  interfaces. 
With  object  models,  standard  data  elements  are  typically  associated  with  the  atomic  data 
attributes  that  represent  shared  data. 

□  Extensible  Markup  Language  (XML)-based  information  is  the  widely  accepted  choice  of 
21st  Century  industry  data/metadata  interchange  and  is  vital  to  the  DoD’s  interoperability 
strategy.  XML  is  widely  used  for  metadata  definition,  management,  and  exchanges.  Integrating 
XML  with  middleware  technologies,  Common  Object  Request  Broker  Architecture  (CORBA) 
for  example,  and  core  database  technologies  will  provide  the  capability  to  exchange  DoD 
mission-area  data  among  heterogeneous  environments.  Refer  to  2. 5.4.1  for  XML  standard. 

Information  Exchange  standards  help  form  the  Common  Operating  Environment  (COE),  ensuring  the 
use  of  system  or  application  formats  that  can  share  data.  Key  references  include  2.5.3,  for  Structured 
Query  Language  (SQL)  standards  in  Data  Management  Services  and  2.5.4  for  Data  Interchange 
Services. 

In  distributed  databases,  other  types  of  data  messaging  may  be  used  as  long  as  they  remain  Defense 
Data  Dictionary  System  (DDDS)-compliant. 
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4.8.1  Tactical  Information  Exchange  Standards 

This  section  addresses  standards  for  the  following  types  of  tactical,  information-exchange  messages: 

□  Bit-oriented  fixed  and  variable  formatted  Tactical  Data  Link  (TDL)  standards  which  allow  real- 
or  near-real-time  tactical,  digital-information  exchange  among  air,  ground,  and  maritime 
components  of  United  States  (U.S.),  North  Atlantic  Treaty  Organization  (NATO),  other  allies, 
and  friendly  nations. 

□  Character  based  information  standards,  which  provide  common,  human-readable,  and 
media-independent  messages  used  for  planning  and  execution  in  joint  and  combined  operations 
among  U.S.  forces,  NATO,  other  allies,  and  friendly  nations. 

4.8. 1.1  Bit-Oriented  Formatted  Messages 

Link  16  is  a  secure,  jam-resistant,  nodeless  data  link  that  uses  the  Joint  Tactical  Information 
Distribution  System  (JTIDSj/Multi functional  Information  Distribution  System  (MIDS)  time-division, 
multiple-access  (TDMA)  protocols,  conventions,  and  fixed-message  formats.  Link  16  provides  for  the 
real/near-real-time  exchange  of  air,  space,  surface,  subsurface,  and  ground  tracks,  and  orders  and 
commands  among  participating  units.  MIL-STD-6016B  defines  the  Link  16  message  set,  minimum 
implementation,  data  forwarding,  and  system  implementation  specifications,  and  a  common  data 
element  dictionary  (DED). 

4.8.1.1(a)  Emerging.  The  Joint  Tactical  Data  Link  Management  Plan  (JTDLMP)  identifies  the 
emerging  Integrated  Broadcast  Service  (IBS)  standard  as  a  member  of  the  Joint  Family  of  TDL 
Message  Standards.  The  IBS  TIDP  defines  CMF  data  elements  and  forwarding  rules  between  IBS  and 
other  members  of  the  Joint  Family  of  TDF  Message  Standards.  The  IBS  TIDP  is  under  the 
configuration  management  authority  of  the  IBS  Message  Standard  Working  Group  (MSWG).  IBS 
MSWG  products  that  impact  joint  interoperability  with  TDFs  are  submitted  by  the  MSWG  to  the  TDF 
CCB  for  joint  approval.  The  following  standard  is  emerging: 

-  IBS  Technical  Interface  Design  Plan  (TIDP). 

4.8.1. 2  Character-Based  Formatted  Messages 

USMTF  messages  are  jointly  agreed,  fixed-format,  character-oriented  messages  that  arc 
human-readable  and  machine-processable.  USMTFs  are  the  mandatory  standard  for  record  messages 
when  communicating  with  the  Joint  Staff,  Combatant  Commands,  and  Service  Components. 

4.8.1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

4.8.1 .3  Binary  Floating-Point  Data  Interchange 

ANSI/IEEE  754-1985  defines  formats  and  functional  requirements  for  processing  binary  floating-point 
numbers  including  infinities  and  not-a-number  values.  A  few  standards  with  a  larger  scope  define  their 
own  specialized,  binary  floating-point  format  for  use  within  the  scope  of  that  standard. 

4.8.1.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

4.8.2  XML-based  Information  Exchange 

XML  is  a  markup  language,  based  on  the  Standard  Generalized  Markup  Language  (SGML),  describing 
structural  information  for  data  (or  documents)  in  tagged  format.  The  tags  themselves  are  not  predefined, 
but  user-defined,  which  enables  flexibility  in  XML’s  usage.  In  other  words,  XML  models  structural 
information  that  is  data  independent  of  tag  names.  XML  is  independent  of  any  platform  and  is  machine  - 
and  human-readable,  enabling  it  to  be  effectively  used  for  data/metadata  interoperability.  This  section 
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is  concerned  with  the  exchange  involving  XML  data  formats.  Examples  of  such  data  formats  include 
object  meta-data,  Application  Program  Interfaces  (APIs)  for  database,  transaction  request-receive, 
mathematical  equations,  etc.  Refer  to  Section  2.5.4. 1  for  both  XML  and  XML  Schema  Standards. 1 * 3 

4.8.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 


1  In  order  to  facilitate  interoperability,  the  DoD  COE  has  established  an  XML  Registry  for  collection,  storage  and  dissemination 
of  XML  components  (schemas/DTD,  XML  tags,  elements,  XST/XSL  style  sheets,  etc.).  The  DoD  COE  XML  Registry  is 
designated  to  be  the  single  authoritative  DoD  repository  for  these  XML  components.  System  developers  using  XML  for  public 
interface  are  required  to  consult  XML  Registry  before  creating  new  components  and  reuse  existing  XML  where  practical. 
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Section  5:  Human-Computer  Interface  Standards 

5.1  Introduction 

This  section  provides  a  common  framework  for  Human-Computer  Interface  (HCI)  design  and 
implementation  in  Department  of  Defense  (DoD)  automated  systems. 

5.2  Purpose 

This  section  focuses  on  standardizing  user  interface  design  and  implementation  options,  thus  enabling 
DoD  applications  within  a  given  domain  to  appear  and  behave  consistently.  The  standardization  of  HCI 
appearance  and  behavior  within  DoD  is  expected  to  result  in  higher  productivity;  shorter  training  time; 
and  reduced  development,  operation,  and  support  costs. 

5.3  Scope  (Applicability) 

Section  5  addresses  standards  for  the  presentation  and  dialogue  of  the  HCI.  For  Application  Program 
Interface  (API)  definitions  and  protocols,  see  JTA  Section  2. 

5.4  Background 

The  objective  of  system  design  is  to  ensure  system  reliability  and  effectiveness.  To  achieve  this 
objective,  the  human  must  be  able  to  effectively  interact  with  the  system.  Operators,  administrators,  and 
maintainers  interact  with  software-based  information  systems  using  the  system’s  HCI.  The  HCI 
includes  the  appearance  and  behavior  of  the  interface,  physical  interaction  devices,  graphical 
interaction  objects,  and  other  human-computer  interaction  methods.  A  good  HCI  is  both  easy  to  use  and 
appropriate  to  the  operational  environment.  It  exhibits  a  combination  of  user-oriented  characteristics 
such  as  intuitive  operation,  ease  and  retention  of  learning,  facilitation  of  user-task  performance,  and 
consistency  with  user  expectations.  The  need  to  learn  the  appearance  and  behavior  of  different  HCIs 
used  by  different  applications  and  systems  increases  both  the  training  burden  and  the  probability  of 
operator  error.  Interfaces  that  exhibit  a  consistent  appearance  and  behavior  both  within  and  across 
applications  and  systems  are  required. 

5.5  General  User  Interface  Design 

The  predominant  types  of  HCIs  include  graphical  user  interfaces  (GUIs)  and  character-based  interfaces. 
Although  GUIs  are  the  preferred  user  interface,  some  specialized  devices  may  require  use  of 
character-based  interfaces  due  to  operational,  technical,  or  physical  constraints.  These  specialized 
interfaces  shall  be  defined  by  domain-level  style  guides  and  further  detailed  in  system-level  user 
interface  specifications.  In  order  to  present  a  consistent  user  interface,  applications  shall  not  mix 
interface  styles;  for  example,  mixing  character-based  interfaces  and  GUIs  or  combining  Windows  and 
Motif  style  elements. 

5.5.1  Graphical  User  Interface 

When  developing  DoD  automated  systems,  the  GUI  shall  be  based  on  one  commercial  user  interface 
style  guide  consistent  with  5.6.1.  Hybrid  GUIs  that  mix  user  interface  styles  (e.g.,  Motif  with  Microsoft 
Windows)  shall  not  be  created.  A  hybrid  GUI  is  composed  of  toolkit  components  from  more  than  one 
user  interface  style.  When  selecting  commercial  off-the-shelf  (COTS)/Government  off-the-shelf 
(GOTS)  applications  for  integration  with  developed  DoD  automated  systems,  maintaining  consistency 
in  the  user  interface  style  shall  be  a  goal.  An  application  delivers  the  user  interface  style  that  matches 
the  host  platform  (i.e.,  Motif  on  a  UNIX  platform  and  Windows  on  an  NT  platform).  This  style 
conforms  to  commercial  standards,  with  consistency  in  style  implementation  regardless  of  the 
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development  environment  used  to  render  the  user  interface.  Applications  that  use  platform-independent 
languages  (such  as  Java)  deliver  the  same  style  as  the  native  application  on  the  host  platform. 

5.5.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

5.5.2  Character-Based  Interfaces 

Character-based  interfaces,  primarily  textual,  are  sometimes  required  for  specialized  devices  due  to 
operational,  technical,  or  physical  constraints. 

5.5.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

5.6  Style  Guides 

A  style  guide  is  a  document  that  specifies  design  rules  and  guidelines  for  the  look  and  behavior  of  the 
user  interaction  with  a  software  application  or  a  family  of  software  applications. 

The  goal  of  a  style  guide  is  to  improve  human  performance  and  reduce  training  requirements  by 
ensuring  consistent  and  usable  design  of  the  HCI  across  software  modules,  applications,  and  systems. 
The  style  guide  represents  “what”  user  interfaces  should  do  in  terms  of  appearance  and  behavior  and 
can  be  used  to  derive  HCI  design  specifications  defining  “how”  the  rules  are  implemented  in  the 
application  code.  Figure  5-1  illustrates  the  hierarchy  of  style  guides  that  shall  be  followed  to  maintain 
consistency  and  good  HCI  design  within  DoD.  This  hierarchy  provides  a  framework  that  supports 
iterative  prototype-based  HCI  development.  The  process  starts  with  top-level  general  guidance  and 
uses  prototyping  activities  to  develop  system-specific  design  rules.  The  interface  developer  shall  use 
the  selected  commercial  GUI  style  guide  and  the  appropriate  domain-level  style  guide  for  specific  style 
decisions,  along  with  input  of  human  factors  specialists  to  create  the  system-specific  HCI.  The 
following  paragraphs  include  guidance  regarding  the  style  guide  hierarchy  levels. 
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Figure  5-1:  HCI  Development  Guidance 
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5.6.1  Commercial  Style  Guides 

A  commercial  GUI  style  shall  be  selected  as  the  basis  for  user  interface  development.  The  GUI  style 
selected  is  usually  driven  by  the  mandates  specified  in  Section  2  (User  Interface  Services  and  Operating 
System  Services). 

5.6.1 .1  X-Window  Style  Guides 

If  an  X- Windows-based  environment  is  selected,  market-driven  industry  standards  shall  be  used. 
5.6.1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

5.6. 1.2  Windows  Style  Guide 

Windows  provides  the  visual  means  by  which  the  user  can  interact  with  an  application  program.  The 
standards  in  this  service  define  the  user  interface  in  terms  of  appearance  and  behavior  according  to 
commercial  practices  for  Windows-based  interfaces.  For  a  Windows-based  environment, 
market-driven  industry  standards  shall  be  used. 

5.6.1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

5.7  Symbology 

The  puipose  of  warfighting  symbology  is  to  convey  information  about  objects  in  the  warfighter 
battlespace.  The  display  of  warfighting  symbology  has  evolved  from  a  static,  manual  operation  to 
include  fully  automated,  computer  generation.  This  evolution  has  resulted  in  the  fielding  of  many 
system-specific  symbology  implementations  by  the  Combatant  Commands,  Services,  and  Agencies  to 
meet  the  mission  requirements  of  the  warfighter.  The  “C4I  for  the  Warrior”  concept,  signed  by  the 
Chairman  of  the  Joint  Chiefs  of  Staff  in  June  1992,  brings  together  C4I  functions  to  provide  the 
warfighter  with  a  seamless,  real-time,  true  representation  of  the  battlespace.  To  achieve  this  capability, 
standardization  of  warfighting  symbology  is  playing  an  integral  role  in  achieving  interoperability 
during  joint  service  operations.  Symbology  has  been  determined  to  be  a  critical  interoperability  factor 
in  today  and  tomorrows  digital  battlespace. 

5.7(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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6.1  Introduction 

This  section  discusses  Information  Security  Standards  for  the  Joint  Technical  Architecture  (JTA). 
National  Security  Systems  (NSS)  standards  should  be  selected  such  that  the  resultant  systems  and 
components  meet  validation  requirements  stipulated  in  National  Telecommunications  and  Information 
Systems  Security  Policy  (NTISSP)  No.  11.  Subject:  National  Policy  Governing  the  Acquisition  of 
Information  Assurance  (IA)  and  IA-enabled  Information  Technology  (IT)  Products.  All  other  IT 
systems  should  follow  Federal  Information  Processing  Standards  (FIPS)  PUBs  on  security  standards 
and  guidelines. 

6.2  Purpose 

This  section  provides  the  emerging  information  security  standards  necessary  to  implement  an 
appropriate  level  of  protection  for  Department  of  Defense  (DoD)  Information  Systems. 

6.3  Scope 

The  standards  mandated  in  this  section  apply  to  all  DoD  IT  systems.  This  section  complies  with  the 
publication,  “Information  Assurance  through  Defense  in  Depth”  (February  2000),  and  the  DoD  CIO 
Guidance  and  Policy  Memorandum  No.  6-8510-DoD  Global  Information  Grid  Information  Assurance. 

The  security  organization  is  based  on  the  Information  Assurance  Technical  Framework  (IATF) 
release  3.0,  September  2000.  Security  issues  are  divided  into  the  following  categories:  the  (local) 
computing  environment  (6.4),  enclave  boundaries  (6.5),  network  and  infrastructure  (6j5)  (both  internal 
and  external  to  enclaves),  and  supporting  infrastructures  (6/7).  The  category  “Evaluation  Criteria”  (6.8) 
has  been  added  to  address  use  of  common  criteria. 

6.4  Computing  Environment 

This  section  covers  security-related  standards  for  the  local  computing  environment  as  defined  by  the 
IATF.  This  includes  end-user  workstations  (both  desktop  and  laptop)  and  servers.  Note  that  some 
individual  computing  environments  also  need  some  of  the  services  of  enclave  boundaries  (e.g.,  virus 
detection).  This  section  is  further  divided  into  applications  (including  Web  browsing,  e-mail,  and 
operating  system[OS])  and  cryptographic  security  services. 

6.4.1  Applications 

This  section  provides  mandated  and  emerging  standards  for  secure  Web  browsing. 

6.4.1. 1  Secure  Web  Browsing 

This  service  identifies  the  protocol  used  to  provide  communications  privacy  over  a  network.  The 
protocol  allows  applications  to  communicate  in  a  way  designed  to  prevent  eavesdropping,  tampering, 
or  message  forgery  in  e-mail  packages.  World  Wide  Web  (WWW)  services  provide  abilities  for 
navigation  and  data  transport  across  the  Internet.  The  protocol  encapsulates  various  higher-level 
protocols  and  is  application  independent. 

6.4.1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.4.1. 2  Secure  Messaging 

This  service  applies  to  the  use  of  security  implementations  for  the  Defense  Message  System  (DMS),  the 
access  control  capabilities  for  communications  with  allied  partners  and  for  e-mail. 
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6.4.1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.4.1. 3  Access  Control 

Access  control  is  the  process  to  limit  access  to  the  resources  of  a  system  only  to  authorized  processes 
or  other  systems  in  a  network. 

6.4.1. 3.1  Identification  and  Authentication  Control:  Passwords 

The  identification  process  enables  recognition  of  an  entity  (subject  or  object)  by  a  computer  system — 
generally  by  the  use  of  unique  machine-readable  user  names.  Authentication  establishes  the  validity  of 
a  claimed  identity.  This  service  applies  to  all  instances  where  Distributed  Computing  Environment 
(DCE)  1.1  is  not  used.  If  DCE  1.1  is  used,  see  6.4.1. 3.2. 

6.4.1.3.1(a)  Emerging.  IETF  RFC  2289,  A  One-Time  Password  System,  February  1998,  provides 
authentication  for  system  access  (login) — and  other  applications  requiring  authentication — that  is 
secure  against  passive  attacks  based  on  replaying  captured  reusable  passwords.  The  One-Time 
Password  System  evolved  from  the  S/KEY  One-Time  Password  System  released  by  Bellcore.  The 
following  standard  is  emerging  for  one-time  password  systems: 

-  IETF  RFC  2289,  A  One-Time  Password  System,  February  1998. 

Two  guidance  documents:  NCSC-TG-017,  A  Guide  to  Understanding  Identification  and 
Authentication  in  Trusted  Systems,  1  September  1991  (http://www.fas.org/irp/nsa.rainbow/tg017.htm); 
and  CSC-STD-002,  DoD  Password  Management  Guidance,  12  April  1985 
(http://www.radium.ncsc.mil/tpep/library/rainbow.htm). 

6.4.1. 3.2  Authentication  Servers 

This  section  provides  emerging  standards  for  Authentication  Servers. 

6.4.1.3.2(a)  Emerging.  When  Remote  Dial-In  Authentication  is  required,  the  following  standard  is 
emerging: 

-  IETF  RFC  2138  Remote  Authentication  Dial  In  User  Service  (RADIUS),  April  1997. 

6.4.1 .4  Data  Labeling 

This  service  addresses  the  identification  of  security  labels  to  be  used  with  data.  The  data  to  which  this 
service  applies  is  defined  in  Section  2.5.4. 

6.4.1. 5  Secure  Session 

This  service  provides  a  secure  remote  login  and  other  secure  network  services  over  a  network  that  does 
not  necessarily  provide  security  services. 

6.4.1.5(a)  Emerging.  Secure  Shell  (SSH)  is  a  protocol  for  secure  remote  login  and  other  secure 
network  services  over  an  insecure  network.  The  following  standard  is  emerging  for  securing  specific 
terminal  and  X- Windows  sessions: 

-  draft-ietf-secsh-architecture-13.txt,  Secure  Shell  (SSH)  Protocol  Architecture, 

23  September  2002. 
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6.4.1. 6  Secure  File  Transfer 

This  service  provides  security  requirements  associated  with  the  transfer  of  binary  and  text  files  between 
user  systems. 

6.4.1 .6(a)  Emerging.  IETF  RFC  2228,  File  Transfer  Protocol,  October  1997,  defines  extensions  to  the 
File  Transfer  Protocol  (FTP)  standard  (STD9/RFC  959).  These  extensions  provide  strong 
authentication,  integrity,  and  confidentiality  on  both  the  control  and  data  channels.  IETF  RFC  2228  also 
introduces  new  optional  commands,  replies,  and  file  transfer  encodings.  The  following  standard  is 
emerging: 

-  IETF  RFC  2228  File  Transfer  Protocol,  October  1997. 

6.4.1. 7  Secure  Distributed  Computing 

This  service  identifies  the  standards  to  be  used  when  security  is  required  in  association  with  distributed 
computing.  Distributed  computing  allows  various  tasks,  operations,  and  information  transfers  to  occur 
on  multiple  physically  or  logically  dispersed  computer  platforms. 

Distributed  Computing  Environment  (DCE)  Authentication  and  Security  Specification  C311, 

August  1997,  is  a  draft  Open-Group  Specification  for  DCE. 

The  Common  Object  Request  Broker  Architecture  (CORBA)  Security  Services  define  a  software 
infrastructure  that  supports  access  control,  authorization,  authentication,  auditing,  delegation, 
non-repudiation,  and  security  administration  for  distributed-object-based  systems.  This  infrastructure 
can  be  based  on  existing  security  environments  and  can  be  used  with  existing  permission  mechanisms 
and  login  facilities.  The  key  security  functionality  is  confined  to  a  trusted  core  that  enforces  the 
essential  security  policy  elements.  Since  the  CORBA  Security  Services  are  intended  to  be  flexible,  two 
levels  of  conformance  may  be  provided.  Level  1  provides  support  for  a  default  system  security  policy 
covering  access  control  and  auditing.  Level  1  is  intended  to  support  applications  that  do  not  have  a 
default  policy.  Level  2  provides  the  capability  for  applications  to  control  the  security  provided  at  object 
invocation  and  also  for  applications  to  control  the  administration  of  an  application- specific  security 
policy.  Level  2  is  intended  to  support  multiple  security  policies  and  to  provide  the  capability  to  select 
separate  access  control  and  audit  policies. 

6.4.1.7(a)  Emerging.  The  following  standards  are  emerging: 

-  OMG  document  formal/01-03-08,  Security  Services  Specification,  Version  1 .7,  March  2001 . 

6.4.1. 8  Operating  System  Security 

This  service  defines  the  protection  profile,  and  the  levels  of  such  protection  profiles,  to  be  applied  to  the 
operating  system  (OS).  A  protection  profile  is  defined  in  the  Common  Criteria  (see  6.8.1). 

6.4.1.8(a)  Emerging.  For  the  application  platform  entity,  the  following  protection  profiles  are 
emerging  for  the  acquisition  of  security  functionality  for  operating  systems  consistent  with  the  required 
level  of  trust. 

For  basic  robustness: 

-  Controlled  Access  Protection  Profile,  Version  1  .d,  NSA,  8  October  1 999. 
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For  medium  robustness: 

-  Labeled  Security  Protection  Profile,  Version  1  .b,  NSA,  8  October  1 999. 

6.4.2  Cryptographic  Security  Services 

To  support  interoperability  using  encrypted  messages,  products  must  share  a  common  communications 
protocol.  This  protocol  must  include  common  cryptographic  message  syntax,  common  cryptographic 
algorithms,  and  common  modes  of  operation  (e.g.,  cipher-block  chaining).  The  mechanisms  to  provide 
the  required  security  services  are  as  follows. 

6.4.2. 1  Encryption  Algorithms 

Encryption  algorithms  are  a  set  of  mathematical  rules  for  rendering  information  unintelligible  by 
affecting  a  series  of  transformations  to  the  normal  representation  of  the  information  through  the  use  of 
variable  elements  controlled  by  a  key. 

6.4.2.1(a)  Emerging.  The  following  standard  is  emerging  for  encryption  of  sensitive  but  unclassified 
(SBU)  data: 

-  FIPS  PUB  197,  Advanced  Encryption  Standard  (AES),  26  November  2001 . 

6.4.2. 2  Hash  Algorithms 

Key-Hashing  for  Message  Authentication  (HMAC)  is  a  mechanism  for  message  authentication  using 
cryptographic  hash  functions,  and  can  be  used  with  any  iterative  hash  function  in  combination  with  a 
shared-secret  key.  The  cryptographic  strength  of  HMAC  depends  on  the  properties  of  the  underlying 
hash  function.  Note  that  HMAC  prevents  “extension”  attacks  that  iterative  hash  functions  do  not 
prevent. 

6.4.2.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.4.2.3  Signature  Algorithms 

A  signature  algorithm  is  an  algorithm  developed  to  assure  message-source  authenticity  and  integrity. 
The  intent  of  the  signature  is  to  provide  a  measure  of  assurance  that  the  person  signing  the  message 
actually  sent  the  message  that  is  signed,  and  that  the  content  of  the  message  has  not  been  changed. 

6.4.2.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.4. 2.4  Cryptographic  Tokens 

Cryptographic  tokens  arc  portable,  user-controlled,  physical  devices  used  to  store  cryptographic 
information  and  possibly  to  perform  cryptographic  functions.  A  cryptographic  token  is  used  to  validate 
an  end  entity’s  identification  and  bind  that  identity  to  its  public  key. 

6.4.2.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.4.2.5  Cryptographic  APIs 

Cryptographic  algorithms  are  the  source  code  formats  and  procedures  through  which  an  application 
program  accesses  cryptographic  hash  algorithms,  digital  signature  algorithms,  and  key  management 
algorithms. 

6.4.2.5(a)  Emerging.  The  Generic  Security  Service-Application  Program  Interface  (GSS-API),  as 
defined  in  IETF  RFC  1508,  September  1993,  provides  security  services  to  callers  in  a  generic  fashion, 


JTA  Version  6.0,  Final 
3  October  2003 


Section  6:  Information  Security  Standards 


Vol.  11-61 


supportable  with  a  range  of  underlying  mechanisms  and  technologies  and  hence  allowing  source-level 
portability  of  applications  to  different  environments.  IETF  RFC  1508  defines  GSS-API  services  and 
primitives  at  a  level  independent  of  an  underlying  mechanism  and  programming  language  environment. 
IETF  RFC  2743,  GSS-API,  Version  2.0,  J.  Finn,  Update  1,  January  2000,  revises  IETF  RFC  1508, 
making  specific,  incremental  changes  in  response  to  implementation  experience  and  liaison  requests. 
The  following  standard  is  emerging: 

-  IETF  RFC  2743,  Generic  Security  Service  Application  Program  Interface,  Version  2, 

1  January  2000. 

The  IETF  Draft,  Independent  Data  Unit  Protection  Generic  Security  Service  Application  Program 
Interface  (IDUP-GSS-API),  C.  Adams,  25  March  1997,  http://rfc2479.x42.com,  extends  the  GSS-API 
(IETF  RFC  1508)  for  non-session  protocols  and  applications  requiring  protection  of  a  generic  data  unit 
(such  as  a  file  or  message)  independent  of  the  protection  of  any  other  data  unit  and  independent  of  any 
concurrent  contact  with  designated  “receivers”  of  the  data  unit.  An  example  application  is  secure 
electronic  mail  in  which  data  needs  to  be  protected  without  any  online  connection  with  the  intended 
recipient(s)  of  that  data.  Subsequent  to  being  protected,  the  data  unit  can  be  transferred  to  the 
recipient(s) — or  to  an  archive — perhaps  to  be  processed  as  unprotected  days  or  years  later.  The 
following  standard  is  emerging: 

-  IETF  RFC  2479,  Independent  Data  Unit  Protection  Generic  Security  Service  Application 
Program  Interface  (IDUP-GSS-API),  December  1998. 

6.4.2.6  Cryptographic  Key  Algorithms 

Cryptographic  key  algorithms  are  mathematical  expressions  that  develop  a  sequence  of  symbols  that 
controls  the  operation  of  encipherment  and  decipherment. 

6.4.2.6(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6. 4.2.7  Cryptographic  Modules 

This  section  provides  mandated  standards  for  Cryptographic  Modules.  Also  see  the  JTA’s  cryptologic 
subdomain. 

6.4.2.7(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.5  Enclave  Boundary 

This  section  defines  standards  for  devices  to  support  effective  control  and  monitoring  of  the  data  flows 
into  and  out  of  a  physical  or  logical  enclave.  This  provides  boundary  defenses  for  those  components 
within  the  enclave  that  cannot  defend  themselves  due  to  technical  or  configuration  problems. 

6.5.1  Firewall 

A  firewall  is  a  system  or  combination  of  systems  that  enforces  a  boundary  between  two  or  more 
networks.  The  puipose  of  a  firewall  is  to  protect  internal  information  systems  from  external  attacks. 
Firewalls  address  the  requirement  for  authorized  FAN  users  and  administrators,  as  well  as  individual 
workstations  or  personal  computer  users,  to  safely  access  and  be  accessed  by  trusted  external  network 
connections. 
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6.5.1(a)  Emerging.  The  following  emerging  standards  will  apply  to  Firewall  devices  in  Basic 
Robustness  environments: 

-  U.S.  Government  Traffic  Filter  Firewall  Protection  Profile  for  Low  Risk  Environments, 

Version  1.1,  April  1999. 

-  U.S.  Department  of  Defense  Application-level  Firewall  Protection  Profile  for  Basic  Robustness 

Environments,  Version  1.0,  June  2000. 

The  following  emerging  standards  will  apply  to  Firewall  devices  in  Medium  Robustness  environments: 

-  U.S.  Department  of  Defense  Traffic  Filter  Firewall  Protection  Profile  for  Medium  Robustness 

Environments,  Version  1.4,  1  May  2000. 

-  U.S.  Department  of  Defense  Application-level  Firewall  Protection  Profile  for  Medium 
Robustness  Environments,  Version  1 .0,  28  June  2000. 

For  firewall  standards,  see  http://csrc.nist.gov/cc/pp. 

6.5.2  Guards 

Guards  enable  users  to  exchange  data  between  private  and  public  networks,  which  is  normally 
prohibited  due  to  information  confidentiality.  Guard  technology  can  bridge  across  security  boundaries 
by  providing  some  of  the  interconnectivity  required  between  systems  operating  at  differing  security 
levels. 

6.5.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.5.3  Remote  Access 

Remote  access  is  the  ability  for  a  user  to  log  in  to  a  server  from  a  remote  location.  For  security,  the  user 
must  first  be  authenticated  before  gaining  access. 

6.5.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.5.4  Malicious  Code 

This  service  provides  protection  against  malicious  code  (e.g.,  viruses,  worms,  and  logic  bombs). 
6.5.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.6  Network  and  Infrastructure 

This  section  addresses  the  standards  for  secure  networks  at  the  network  layer  protocol  and  below,  as 
well  as  its  basic  infrastructure  (e.g.,  naming  services).  They  include  security  standards  for 
communication  protocols  (at  the  network  layer,  link  layer,  and  physical  layer,  as  well  as  related  naming 
services)  and  for  Virtual  Private  Networks  (VPNs)  for  secure  communications  using  potentially 
insecure  networks.  Systems  processing  classified  information  must  use  Type  1  National  Security 
Agency  (NSA)-approved  encryption  products  to  provide  both  confidentiality  and  integrity  security 
services  within  the  network. 

6.6.1  Network  Layer 

The  Network  layer  is  layer  3  of  the  Open  Systems  Interconnect  (OSI)  7  Layer  Reference  Model. 
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6.6.1(a)  Emerging.  The  following  standard  is  emerging  for  Virtual  Private  Networks  (VPN)  devices 
operating  at  the  Network  Layer: 

-  Virtual  Private  Network  Protection  Profile  for  Protecting  Sensitive  Information,  Version  1 .0, 

26  February  2000. 

6.6.2  Link  Layer 

The  (data)  link  layer  is  layer  2  of  the  Open  Systems  Interconnect  (OSI)  7  Layer  Reference  Model  where 
a  point-to-point  communication  channel  connecting  two  subnetwork  relays  is  established. 

6.6.2(a)  Emerging.  The  Point-to-Point  Protocol  (PPP)  Triple-DES  Encryption  Protocol  (3DESE)  is  a 
complement  to  FIPS  PUB  46-3.  The  following  standard  is  emerging: 

-  IETF  RFC  2420,  The  PPP  Triple-DES  Encryption  Protocol  (3DESE),  September  1998. 

The  ATM  Forum  has  also  established  requirements  and  control  implementation  for  security  of  ATM 
networks.  The  following  standards  are  emerging  for  secure  ATM  networks: 

-  ATM  Forum,  af-sec-0096.000,  ATM  Security  Framework  Version  1 .0,  February  1 998. 

-  ATM  Forum,  af-sec-01 00.002,  ATM  Security  Specification  Version  1.1,  March  2001 . 

6.6.3  Physical  Layer 

The  physical  layer,  Layer  1  of  the  OSI  7  Layer  Reference  Model,  provides  the  mechanical,  electrical, 
functional,  and  procedural  means  to  activate,  maintain,  and  deactivate  physical  connections  for  bit 
transmission  between  data-link  entities. 

6.6.3(a)  Emerging.  The  following  IEEE-approved  standard  for  Local  Area  Network  (LAN)  security 
and  Metropolitan  Area  Network  (MAN)  security  is  emerging: 

-  IEEE  802.10-1998,  IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  Standard  for 
Interoperable  LAN/MAN  Security  (SILS),  17  September  1998. 

-  IEEE  802.10a-1999,  IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  Supplement 
to  Standard  for  Interoperable  LAN/MAN  Security  (SILS)  -  Security  Architecture  Framework 
(Clause  1),  22  March  1999. 

-  IEEE  802.10c- 1998,  IEEE  Standards  Interoperable  LAN/MAN  Security  (SILS)  -  Key 
Management  (Clause  3),  17  April  1998. 

6.6.4  Naming  Service 

A  naming  service:  (1)  is  used  to  construct  large,  enterprise- wide  naming  graphs  where  naming  contexts 
model  “directories”  or  “folders”  and  other  names  identify  “document”  or  “file”  types  of  objects;  and 
(2)  is  used  as  the  backbone  of  an  enterprise-wide  filing  system. 

6.6.4(a)  Emerging.  The  Domain  Name  System  (DNS)  has  become  a  critical  operational  part  of  the 
Internet  infrastructure,  yet  it  has  no  strong  security  mechanisms  to  ensure  data  integrity  or 
authentication. 

The  DNS  is  also  a  critical  operational  part  of  a  TCP/IP-based  infrastructure,  and  authentication  and 
integrity  mechanisms  are  often  necessary  to  protect  it.  In  cases  where  DNS  authentication  is  needed  and 
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a  shared  secret  key  approach  is  appropriate,  in  particular  in  zone  transfers  between  authoritative  servers, 
the  following  standard  is  emerging: 

-  IETF  RFC  2845,  Secret  Key  Transaction  Authentication  for  DNS  (TSIG),  May  2000. 

In  other  cases  where  DNS  authentication  and  integrity  protection  is  needed,  the  DNSSEC  standards  are 
emerging.  DNSSEC  defines  extensions  to  DNS  to  support  security  requirements,  data  integrity  and 
authentication,  through  cryptographic  digital  signatures.  However,  DNSSEC  as  defined  by  IETF 
RFC  2535  has  been  shown  to  have  serious  problems,  so  IETF  RFC  2535  is  being  updated.  Once  IETF 
RFC  2535  is  updated  to  repair  these  problems,  it  is  expected  to  be  mandated.  The  following  standard  is 
emerging  for  DNS  security: 

-  IETF  RFC  2535,  DNS  Security  Extensions,  March  1999. 

6.6.5  Directory  Service 

A  directory  service  provides  names,  locations,  and  other  information  about  people  and  organizations. 
In  a  network,  this  directory  information  may  be  used  for  e-mail  addressing,  user  authentication 
(e.g.,  logins  and  passwords),  or  network  security  (e.g.,  user  access  rights). 

6.6.5(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.7  Supporting  Infrastructures 

This  section  addresses  standards  for  service  areas  providing  overall  security  support.  It  includes 
standards  for  public -key  infrastructure  (PKI)  and  intrusion  detection  systems  (IDSs). 

6.7.1  Public-Key  Infrastructure 

A  PKI  comprises  the  people,  policies,  procedures,  and  computing/telecommunications  resources 
needed  to  manage  public  keys  used  by  information  systems.  A  PKI  supports  the  following  security 
services:  authentication,  data  integrity,  non-repudiation,  confidentiality,  and  (optionally)  authorization. 

A  PKI  supports  “X.509  public -key  certificates,”  as  defined  in  International  Telecommunications  Union 
-  Telecommunications  (ITU-T)  Recommendation  X.509.  A  public-key  certificate  is  a  data  structure 
that  binds  a  subject  (i.e.,  people,  applications  programs,  machines,  etc.)  and  the  subject’s  public  key.  A 
public-key  certificate  may  contain  additional  attributes  of  the  subject,  such  as  an  address,  phone 
number,  and  authorization  (access  control)  data. 

A  PKI  may  support  X.509  attribute  certificates.  An  attribute  certificate  binds  a  subject  and  the  subject’s 
authorization  data,  such  as  group  membership,  roles,  clearances,  privileges,  and  restrictions.  The 
authorization  data  does  not  guarantee  access  to  information  resources,  as  the  decision  to  grant  or  deny 
access  is  made  by  the  application  that  uses  the  certificate.  Attribute  certificates  do  not  contain  public 
keys. 

A  private  key  is  used  to  digitally  sign  data,  such  as  messages,  files,  and  transactions.  The  corresponding 
public  key  is  used  to  verify  the  signature.  A  private  key  can  also  be  used  to  decrypt  data  encrypted  with 
the  corresponding  public  key.  In  the  DoD  medium-assurance  PKI,  the  public/private-key  pairs  used  for 
non-repudiation  or  digital-signature  services  will  be  distinct  from  the  pairs  used  for 
encryption/decryption  services.  Public/private-key  pairs  are  also  used  in  algorithms  that  automatically 
distribute  symmetric,  secret  keys. 
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X.509  public-key  certificates  are  signed  and  issued  by  a  special  user  called  a  certification  authority 
(CA).  A  CA  may  also  revoke  certificates.  X.509  attribute  certificates  are  the  certificates  that  are  signed, 
issued,  and  revoked  by  an  attribute-certificate  issuer. 

The  DoD  medium-assurance  PKI  is  authorized  to  protect  unclassified  and  certain  types  of  sensitive  but 
unclassified  (SBU)  information,  in  accordance  with  the  DoD  Class  3  level  of  information  assurance. 
The  DoD  medium-assurance  PKI  may  also  be  used  for  digital  signature  services,  user  authentication, 
and  community-of-interest  separation  within  certain  types  of  classified  networks  protected  by  Type  I 
cryptography.  The  U.S.  DoD  X.509  Certificate  Policy  specifies  the  permitted  uses  of  a 
medium-assurance  (Class  3)  PKI  in  encrypted  and  unencrypted  networks. 

The  standards  listed  below  are  the  standards  being  used  in  the  DoD  medium-assurance  pilot  PKI.  The 
standards  arc  grouped  according  to  the  categories  defined  in  the  Internet  Draft  entitled  Internet  X.509 
Public-Key  Infrastructure  PKIX  Roadmap,  23  June  1999,  plus  additional  categories  not  mentioned  in 
the  Roadmap. 

6.7.1. 1  PKI  Certificates 

This  section  provides  mandated  and  emerging  standards  for  PKI  Certificates. 

6.7.1.1(a)  Emerging.  The  DoD  medium-assurance  certificate  profile  implements  the  Federal  PKI 
certificate  profile,  which  in  turn  implements  the  Internet  Engineering  Task  Force  (IETF)  profile,  which 
in  turn  implements  the  ITU-T  X.509  profile.  Emerging  certificate  profile  standards  are: 

-  IETF  RFC  2459,  Internet  X.509  Public  Key  Infrastructure  Certificate  and  CRL  Profile, 

January  1999,  as  profiled  by  TWG-98-07. 

-  TWG-98-07,  DoD  Certificate  Policy,  Version  6,  31  May  2002. 

6.7.1 .2  PKI  Operational  Protocol  and  Exchange  Formats 

The  following  paragraphs  address  standards  for  PKI  operational  protocol  and  exchange  formats. 

6.7.1.2(a)  Emerging.  Operational  protocols  deliver  certificates  and  certificate  revocation  lists  (CRLs) 
to  certificate-using  systems.  The  medium-assurance  pilot  uses  IETF  RFC  2559,  a  profile  of  IETF 
RFC  1777,  Fightweight  Directory  Access  Protocol,  version  2,  (FDAPv2),  as  its  operational  protocol. 
The  following  operational  protocol  is  emerging: 

-  IETF  RFC  2559,  Internet  X.509  Public  Key  Infrastructure  Operational  Protocols:  LDAPv2, 
April  1999. 

Certificates  and  CRFs  arc  stored  in  FDAP  servers,  which  are  accessed  by  certificate-using  systems 
through  FDAPv2.  IETF  RFC  2587  specifies  the  minimal  schema  required  to  support  certificates  and 
CRFs  in  an  FDAP  server.  An  emerging  standard  for  FDAP  PKI  servers  is: 

-  IETF  RFC  2587,  Internet  X.509  Public  Key  Infrastructure  LDAPv2  Schema,  June  1999. 

Certificates,  private  keys,  and  other  personal  data  must  be  protected  when  they  are  moved  between 
computers  or  removable  media,  such  as  smart  cards  or  floppy  disks.  For  secure  or  authenticated 
exchange  of  such  personal  data,  the  following  standards  are  emerging: 

-  RSA  Laboratories  Public  Key  Cryptography  Standard  #12,  vl.O:  Personal  Information 
Exchange  Syntax  Standard,  RSA,  24  June  1999. 
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-  RSA  Laboratories  Public  Key  Cryptography  Standard  (PKCS)  #15,  vl  .1 :  Cryptographic  Token 
Information  Format  Standard,  RSA,  6  June  2000. 

6.7.1. 3  PKI  Management  Protocols 

The  following  paragraphs  address  standards  for  PKI  Management  Protocols. 

6.7.1 .3(a)  Emerging.  Management  protocols  support  transactions  involving  management  entities,  such 
as  CAs,  Registration  Authorities  (RAs),  and  Local  Registration  Authorities  (LRAs).  Typical 
transactions  are  user  registration,  certificate  enrollment,  and  certificate  revocation.  The  following 
management  protocols  are  emerging: 

-  IETF  RFC  2315,  Public  Key  Cryptography  Standard  (PKCS)  #7,  Cryptographic  Message 
Syntax,  Version  1.5,  March  1998. 

-  IETF  RFC  2314,  PKCS  #10,  Certification  Request  Syntax,  Version  1 .5,  March  1998. 

Although  IETF  RFC  2315  and  2314  are  based  upon  de  facto  standards  from  RSA  Laboratories,  Inc.,  the 
IETF  is  incorporating  them  into  open,  consensus-based  standards,  such  as  the  Internet  draft  for 
“Certificate  Management  Messages  over  Cryptographic  Message  Syntax  (CMC).”  As  the  CMC  draft 
matures,  it  will  be  considered  for  adoption  as  an  emerging  standard. 

6.7.1. 4  PKI  API 

The  following  paragraphs  address  standards  for  PKI  API. 

6.7.1.4(a)  Emerging.  API  standards  allow  programmers  to  incorporate  PKI  services  into  their 
applications  in  a  manner  that  supports  applications  portability.  The  following  standard  is  emerging: 

-  RSA  Laboratories  Public  Key  Cryptography  Standard  (PKCS)  #11 ,  v2.10:  Cryptographic  Token 
Interface  Standard,  December  1999. 

6.7.1. 5  PKI  Cryptography 

The  following  paragraphs  address  standards  for  PKI  Cryptography. 

6.7.1.5(a)  Emerging.  The  following  standards  are  emerging: 

-  IETF  RFC  2437,  PKCS  #1 :  RSA  Cryptography  Specifications  Version  2.0,  October  1998. 

-  FIPS  PUB  140-2,  Security  Requirements  for  Cryptographic  Modules,  25  May  2001 . 

For  systems  using  encryption  to  protect  privacy  act  information  and  other  unclassified,  non- Warner  Act 
exempt  information,  the  triple-DES  algorithm  in  the  following  standard  is  emerging: 

-  FIPS  PUB  46-3,  Data  Encryption  Standard,  NIST,  25  October  1999. 

The  following  standard  is  emerging  for  PKI  Class  3  implementations: 

-  FIPS  PUB  180-1 ,  Secure  Hash  Algorithm,  17  April  1995. 

The  following  standard  is  emerging  for  encryption  of  sensitive  but  unclassified  (SBU)  data: 

-  FIPS  PUB  197,  Advanced  Encryption  Standard  (AES),  NIST,  26  November  2001 . 


JTA  Version  6.0,  Final 
3  October  2003 


Section  6:  Information  Security  Standards 


Vol.  11-67 


6.7.2  Key  Management  Infrastructure 

The  following  paragraphs  address  standards  for  Key  Management  Infrastructure. 

6.7.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

6.7.3  Intrusion  Detection  Systems 

The  following  paragraphs  address  standards  for  Intrusion  Detection  Systems  (IDS). 

6.7.3. 1  Intrusion  Detection  Devices 

The  following  paragraphs  address  standards  for  Intrusion  Detection  Devices. 

6.7.3.1(a)  Emerging.  The  following  standards  for  Intrusion  Detection  devices  are  emerging: 

-  Intrusion  Detection  System  Analyzer  Protection  Profile,  Draft  3,  IATF,  15  September  2000. 

-  Intrusion  Detection  System  Sensor  Protection  Profile,  Draft  3,  IATF,  15  September  2000. 

-  Intrusion  Detection  System  Scanner  Protection  Profile  Draft  3,  IATF,  15  September  2000. 

For  intrusion  detection  standards,  see  http://csrc.nist.gov/cc/pp. 

6.7. 3. 2  Intrusion  Detection  Communications  Protocol 

The  Intrusion  Detection  Exchange  Protocol  (IDXP)  is  an  application-level  protocol  for  exchanging  data 
between  intrusion  detection  entities.  IDXP  supports  mutual-authentication,  integrity,  and 
confidentiality  over  a  connection-oriented  protocol.  The  protocol  provides  for  the  exchange  of 
Intrusion  Detection  Message  Exchange  Format  (IDMEF)  messages,  unstructured  text,  and  binary  data. 

6.7.3.2(a)  Emerging.  The  following  Intrusion  Detection  Communications  Protocol  standard  is 
emerging: 

-  draft-ietf-idwq-beep-idxp-04.txt,  Intrusion  Detection  Exchange  Protocol  (IDXP), 

11  September  2001 . 

6.7.3. 3  Intrusion  Detection  Message  Exchange  Format 

The  IDMEF  is  intended  to  be  a  standard  data  format  that  automated  IDS  can  use  to  report  alerts  about 
events  that  they  deem  suspicious.  The  development  of  this  standard  format  will  enable  interoperability 
among  commercial,  open  source,  and  research  systems,  allowing  users  to  implement  heterogeneous 
IDS  across  their  network  infrastructures. 

6.7.3.3(a)  Emerging.  The  following  Intrusion  Detection  Message  Exchange  Format  standard  is 
emerging: 

-  draft-ietf-idwg-idmef-xml-06.txt,  Data  Model  and  Extensible  Markup  Language  (XML) 
Document  Type  Definition,  1 8  September  2001 . 

6.8  Evaluation  Criteria 

This  section  includes  standards  used  to  design,  develop,  and  evaluate  security  components  and  systems. 

6.8.1  Common  Criteria 

The  Evaluation  Criteria  for  Information  Technology  Security  (a.k.a.,  Common  Criteria)  represents  the 
outcome  of  efforts  to  develop  criteria  for  evaluation  of  IT  security  that  arc  widely  useful  within  the 
international  community.  It  is  an  alignment  and  development  of  a  number  of  existing  European,  U.S., 
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and  Canadian  criteria  (e.g.,  ITSEC,  TCSEC,  and  CTCPEC)  respectively.  The  Common  Criteria  is  a 
meta-standard  (a  standard  of  standards)  as  it  is  essentially  a  list  of  selectable  security  requirements 
(functional  and  assurance),  plus  definitions  and  requirements  for  how  to  document  security  capabilities 
and  needs  (as  Security  Targets  and  Protection  Profiles  respectively).  The  Common  Criteria 
Implementation  Board  (CCIB),  working  in  cooperation  with  the  International  Organization  for 
Standardization  (ISO),  has  produced  a  technically  equivalent  document  entitled,  “The  Common 
Criteria  for  Information  Technology  Security  Evaluation  (CC),  Version  2.1  (CC  2.1).”  The  CCIB  has 
fully  aligned  CC  2.1  with  ISO/IEC  15408:1999.  Therefore,  any  security  specifications  written  using 
CC  2.1,  and  IT  products/systems  shown  to  be  compliant  with  CC  2.1,  are  considered  to  be 
ISO/IEC  15408: 1999  compliant.  More  information  on  the  CC  Project  can  be  found  on  the  NIST  Web 
site  at:  http://csrc.ncsl.nist.gov/cc/ccv20/ccv21ist.htm. 

No  emerging  standards  are  in  this  section.  However,  NSA  has  initiated  a  Protection  Profile  effort  to 
provide  recommended  guidance  to  DoD  and  U.S.  Government  entities  in  the  acquisition  of  IT  security 
products.  The  objective  is  to  provide  a  recommended  and,  eventually,  DoD-wide  uniform  set  of 
specifications  for  these  security  devices.  This  will  provide  a  focus  for  the  vendors,  who  will  be 
motivated  to  produce  products  that  satisfy  the  DoD  requirements  as  expressed  in  these  protection 
profiles.  NSA  customers  must  validate  that  these  profiles  accurately  express  DoD  requirements.  Vendor 
input  is  needed  to  ensure  that  these  profiles  represent  security  requirements  realistic  for  a  commercial 
market  product.  Note:  See  profile  list  at  the  Information  Assurance  Technical  Framework  Forum  Web 
site:  www.iatf.net. 

6.8.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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Surveillance,  and  Reconnaissance  Domain 

C4ISR.1  Domain  Description 

This  Domain  (C4ISR)  represents  common  elements  within  a  family  of  related  systems  focusing  on  the 
functional,  behavioral,  and  operational  requirements  needed  to  extend  the  JTA  concept  to  this  specific 
domain  and  its  associated  subdomains. 

The  C4ISR  Domain  consists  of  those  integrated  systems  of  doctrine,  procedures,  organizational 
structures,  personnel,  equipment,  facilities,  and  communications  whose  primary  focus  is  on  one  or 
more  of  the  following  functions: 

□  Support  properly  designated  commanders  in  the  exercise  of  authority  and  direction  over 
assigned  and  attached  forces  across  the  range  of  military  operations. 

□  Collect,  process,  integrate,  analyze,  evaluate,  or  interpret  available  information  concerning 
foreign  countries  or  areas. 

□  Systematically  observe  aerospace,  surface  or  subsurface  areas,  places,  persons,  or  things  by 
visual,  aural,  electronic,  photographic,  or  other  means. 

□  Obtain,  by  visual  observation  or  other  detection  methods,  information  about  the  activities  and 
resources  of  an  enemy  or  potential  enemy,  or  secure  data  concerning  the  meteorological, 
hydrographic,  or  geographic  characteristics  of  a  particular  area. 

This  will  specifically  address  the  information  technology  (IT)  aspect  of  the  C4ISR  Domain.  It  should 
be  noted  that  this  does  not  include  those  systems  or  other  IT  components  specifically  identified  as 
belonging  to  the  Combat  Support  Domain  or  whose  primary  function  is  the  support  of  day-to-day 
administrative  or  support  operations  at  fixed-base  locations.  Examples  of  such  systems  include 
acquisition,  finance,  human  resources,  legal,  logistics,  and  medical  systems,  and  items  such  as 
general-purpose  LANs,  computer  hardware  and  software,  telephone  switches,  transmission  equipment, 
and  outside  cable  plant.  The  position  of  the  C4ISR  Domain  in  the  JTA  Hierarchy  Model  is  shown  in 
Core  Figure  1-2. 

C4ISR.2  Purpose  and  Scope 

The  C4ISR  Domain  identifies  elements  (i.e.,  standards,  interfaces,  and  service  areas)  specific  to  the 
functional  areas  of  command,  control,  communications,  computers,  intelligence,  surveillance,  and 
reconnaissance  that  are  additions  to  those  standards  listed  in  the  JTA  Core.  These  additions  are  common 
to  the  majority  of  C4ISR  systems  and  support  the  functional  requirements  of  C4ISR  systems. 

C4ISR.3  Applicability 

The  elements  listed  in  this  domain  are  mandated  for  use  on  all  emerging  systems  or  upgrades  to  existing 
systems  developed  to  meet  the  functional  area  of  C4ISR.  Users  of  this  document  are  encouraged  to 
review  other  subdomains  to  better  gauge  which  domain  is  applicable. 

C4ISR.4  Information  Processing  Standards 

This  section  is  intended  to  identify  the  data  format  and  information  processing  standards  required  by 
C4ISR  systems  needed  in  addition  to  the  JTA  Core  standards  to  develop  integrated  interoperable 
systems. 
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C4ISR.4.1  Common  Ground  Moving  Target  Indicator  Data  Format 

The  Common  Ground  Moving  Target  Indicator  (CGMTI)  Data  Format  is  a  U.S./NATO  data  format 
used  to  disseminate  imagery  from  airborne  and  spaceborne  sensor  platforms. 

C4ISR.4.1  (a)  Emerging.  The  Common  Ground  Moving  Target  Indicator  (CGMTI)  Format  is  emerging 
as  a  de  facto  U.S./NATO  data  format  for  the  dissemination  of  GMTI  imagery  from  airborne  and 
spaceborne  CGMTI  sensor  platforms.  It  is  being  developed  as  a  product  of  the  CGMTI  Format  Working 
Group,  which  was  established  to  define  and  develop  a  standard  that  facilitates  the  transmission, 
processing,  and  subsequent  fusion  and  display  of  CGMTI  data.  Details  of  the  Working  Group  are 
available  at  the  CGMTI  Web  site  http ://w w w.rl. af . mil/programs/c gmti/.  The  following  document  is 
identified  as  an  emerging  standard  for  systems  that  disseminate  CGMTI  data: 

-  Common  Ground  Moving  Target  Indicator  (CGMTI)  Format  Document  DRAFT 
Version  1.01d5a,  27  April  2001. 

C4ISR.5  Information  Transfer  Standards 

The  information  transfer  standards  and  profiles  described  in  this  section  promote  seamless 
communications  and  information  transfer  interoperability  for  C4ISR  systems  through  the  use  of 
standardized  interfaces  for  end-systems,  networks,  transmission  media,  and  systems  management. 

C4ISR.5.1  Transmission  Media 

Transmission  media  refers  to  the  physical  paths  used  to  transfer  information  among  Components  within 
the  same  system  or  among  different  systems. 

C4ISR.5.1.1  Radio  Communications 

This  section  addresses  standards  that  facilitate  the  interoperability  of  C4ISR  systems  that  utilize  the 
portion  of  the  electromagnetic  spectrum  below  300  GHz  for  wireless  communication. 

C4ISR.5. 1.1.1  Unattended  MASINT  Sensor  Communication  Standards 

Unattended  Measurement  and  Signature  Intelligence  (MASINT)  Sensors  (UMSs)  are  small, 
autonomously  powered,  disposable  systems  that  can  be  deployed  by  airborne  platforms  or  ground 
personnel.  UMS  can  contain  one  or  more  types  of  sensors  (seismic,  acoustic,  IR,  magnetic,  chemical, 
or  radiological)  that  transmit  alarm  messages  or  data  when  triggered  by  enemy  activity.  The  Security 
Equipment  Integration  Working  Group  (SEIWG)-005  standard  specifies  the  frequencies,  data  formats, 
and  protocols  for  this  class  of  sensors  in  order  to  relay  the  data  back,  via  communication  links  and  data 
relays,  to  a  common  exploitation  station. 

C4ISR.5. 1.1. 1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.5.1.2  Network  Standards 

The  Program  Management  Office  for  Night  Vision/Reconnaissance  and  Target  Acquisition  (PM 
NV/RSTA)  has  developed  the  Sensor  Link  Protocol  (SLP)  for  use  as  a  common  local  network  interface 
between  RSTA  sensor  systems  and  a  host  computer  system. 

C4ISR.5. 1.2(a)  Emerging.  The  following  standard  is  emerging: 

-  ICD-SLP-200,  Interface  Control  Document  (ICD)  Title:  Sensor  Link  Protocol,  14  September 
1998. 


JTA  Version  6.0,  Final 
3  October  2003 


C4ISR:  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  Domain  Vol.  11-71 


C4ISR.5.1.3  Platform  to  Ground  Station  Direct  Data  Transfer  Interface 

Mission  Tape  Recorders  are  used  to  capture  the  raw  and  preprocessed  data  on  the  platform.  The  data  is 
then  transferred  to  a  ground  station  via  the  recorded  tape  in  a  standard  format.  The  two  high  rate  digital 
recording  standards  are  ANSI  ID-1  and  DCRSi. 

C4ISR.5. 1.3(a)  Emerging.  The  Air  Group  IV  working  group,  under  the  NATO  Air  Force  Armaments 
Group  (NAFAG)  has  developed  the  NATO  Advanced  Data  Storage  Interface  (NADSI)  NATO 
Standardization  Agreement  (STANAG).  This  STANAG  defines  the  standard  interface  for  the 
interoperability  and  transfer/exchange  of  data  among  Intelligence,  Surveillance,  and  Reconnaissance 
(ISR)  platforms  and  NATO  ground  stations  by  direct  physical  connection  to  data  storage  subsystems. 
This  STANAG  will  be  promulgated  by  the  Chairman  of  the  Military  Agency  for  Standardization 
(MAS). 

The  NADSI  STANAG  4575  defines  a  multiple  layer  protocol  for  the  lower  levels  of  the  interface 
channel  as  defined  in  the  International  Standards  Organization  -  Open  Systems  Interconnection  model 
(ISO/IEC  7498-1).  Additionally,  this  STANAG  is  part  of  the  NATO  Imagery  Interoperability 
Architecture  (NIIA),  which  includes  the  data  format  standards  STANAG  7023  for  primary  and 
STANAG  4545  for  secondary  imagery. 

The  STANAG  4575  interface  is  to  be  incorporated  into  all  removable  data  storage  elements  in  ISR 
Advanced  (i.e.,  non-tape)  Data  Storage  systems  to  allow  the  direct  download  of  ISR  data  to  ground 
stations  via  a  direct  connection.  The  following  document  is  identified  as  an  emerging  standard  for  the 
transfer  of  stored  ISR  data: 

-  NATO  Advanced  Data  Storage  Interface,  (NADSI)  STANAG  4575,  Edition  1 ,  Ratification  Draft. 

C4ISR.5.2  Payload-Platform  Interface 

The  interface  standards  identified  in  this  section  address  interoperability  requirements  for  the 
integration  of  a  C4ISR  payload  (e.g.,  sensor  package,  communications  relay)  into  a  manned  or 
unmanned  aerospace  platform.  It  is  recognized  that  vehicle  interface  characteristics  arc  often  driven  by 
the  requirements  of  legacy  technologies  or  other  onboard  systems.  In  these  cases,  the  JTA  rule  set 
described  in  L9  of  the  JTA  Core,  and  as  interpreted  by  individual  Service/ Agency  JTA  Implementation 
Plans,  should  be  used  to  determine  mandate  applicability.  It  should  be  noted  that  the  standards  in  this 
section  apply  to  the  platform  only  to  the  extent  to  which  they  directly  affect  the  interoperability  of 
onboard  C4ISR  systems.  At  the  present  time,  these  standards  apply  only  to  airborne  reconnaissance 
systems. 

C4ISR.5.2.1  Internal  Communications 

Internal  communications  provide  information  transfer  capabilities  between  the  platform  and  the 
onboard  C4ISR  systems,  subsystems,  and  components.  This  section  identifies  the  standards  necessary 
to  facilitate  interoperability  within  and  between  these  entities. 

C4ISR.5.2.1.1  Fibre  Channel 

Fibre  Channel  is  an  efficient,  high-speed,  serial  data  communication  technology  for  use  in  many 
environments  including  near-real-time  high-speed  data  transfer,  and  local/campus  networking 
environments.  The  Fibre  Channel  Physical  and  Signaling  standards  pertain  to  the  first  three  layers  of 
the  Fibre  Channel  stack  (FCO,  FC1,  and  FC2).  FCO  addresses  the  physical  media,  FC1  discusses  the 
data-encoding  scheme,  and  FC2  addresses  the  framing  protocol  and  flow  control.  The  media  chosen  for 
Fibre  Channel  can  accommodate  speeds  of  133,  266,  and  531  Mbps  and  1.06,  2.12,  and  4.25  Gbps. 
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C4ISR.5.2.1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.5.2.1.2  FireWire 

FireWire  describes  a  serial  bus  that  provides  the  same  services  as  modern  IEEE-standard  parallel  buses. 
It  has  a  64-bit  address  space,  control  registers,  and  a  read/write/lock  operations  set  that  conforms  to 
ISO/IEC  13213: 1994  Information  technology  -  Microprocessor  systems  -  Control  and  Status  Registers 
(CSR)  Architecture  for  microcomputer  buses. 

C4ISR.5.2. 1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.5.2.2  Vehicle/Sensor  Telemetry 

Commands  to  various  Signal  Intelligence  (SIGINT),  Imagery  Intelligence  (IMINT),  and  MASINT 
front-end  equipment  flow  through  airborne  telemetry  systems  to  onboard  LANs.  Sensor  commands  and 
acknowledgments  may  include  position  changes,  mode  changes,  fault  isolation  commands,  and  others. 

Inter-Range  Instrumentation  Group  (IRIG)  Standard  106-01  is  the  primary  telemetry  standard  used 
throughout  the  world  by  both  government  and  industry.  IRIG  Standard  106-01  covers  all  aspects  of 
frequency  division  multiplexing  and  pulse  code  modulation  (PCM)  telemetry,  including  transmitters, 
receivers,  and  tape  recorders.  This  is  one  of  many  comprehensive  standards  prepared  by  the  Telemetry 
Group  of  the  Range  Commanders  Council  (RCC)  to  foster  the  compatibility  of  telemetry  transmitting, 
receiving,  and  signal  processing  equipment  at  member  ranges. 

C4ISR.5.2.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.5.3  Nuclear  Command  and  Control  Information  Transfer 

The  information  transfer  standards  and  profiles  described  in  this  section  promote  seamless 
communications  and  information  transfer  interoperability  for  Nuclear  Command  and  Control  (NCC) 
systems  through  the  use  of  standardized  interfaces  for  end-systems,  networks,  transmission  media,  and 
systems  management. 

C4ISR.5.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.6  Information  Modeling,  Metadata,  and  Information  Exchange  Standards 

The  information  modeling,  metadata,  and  information  exchange  standards  and  profiles  described  in  this 
section  facilitate  interoperability  between  C4ISR  systems  through  the  use  of  standardized  activity 
models,  data  models,  data  definitions,  and  formatted  messages. 

C4ISR.6.1  Information  Exchange  Standards 

Information  Exchange  refers  to  the  exchange  of  information  among  mission-area  applications  within 
the  same  system  or  among  different  systems. 

C4ISR.6.1.1  Target/Threat  Data  Interchange  Standards 

The  National  Target/Threat  Signature  Data  System  (NTSDS)  has  been  designated  as  a  migration 
system,  in  accordance  with  guidance  from  Assistant  Secretary  of  Defense  (ASD)  (C3I)  and  by  the 
Intelligence  Systems  Board  (ISB).  NTSDS  provides  the  Department  of  Defense  (DoD)  signature  data 
community  (e.g.,  ISR  and  MASINT)  signature  data  from  multiple,  geographically  distributed  sites  via 
a  unified  national  system.  NTSDS  Data  Centers  employ  standard  data  parameters  and  formats  for 
stored  target  signatures  for  national  and  DoD  customers. 

C4ISR.6.1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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C4ISR.6.1.2  Nuclear  Command  and  Control  Information  Exchange 

The  following  paragraphs  address  standards  for  Nuclear  Command  and  Control  information  exchange. 
C4ISR.6. 1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.6.2  Sensor  Link  Protocol  (SLP)  Message  Set 

SLP  was  developed  for  use  as  a  common  interface  between  electro-optical  sensor  systems  and  a  diverse 
set  of  host  computer  systems.  SLP  allows  implemented  the  flexibility  to  select  from  a  number  of  open 
protocol  standards  (e.g.,  RS-232/485,  FireWire  or  Universal  Serial  Bus  (USB))  by  decoupling  the 
message  set  from  the  underlying  protocol.  The  SLP  message  set  can  be  used  to  implement  a  common 
digital  data  exchange  mechanism  that  offers  full  remote  operation  and  control  of  sensors  by  a  host 
computing  device  in  both  a  point-to-point  and  networked  environment. 

C4ISR.6.2(a)  Emerging.  The  SLP  message  set  is  defined  in  the  following  emerging  standard: 

-  SLP-MSG-210,  Revision,  Sensor  Link  Protocol  Message  Set,  26  March  2001 . 

C4ISR.7  Human-Computer  Interface  Standards 

The  human-computer  interface  standards  and  profiles  described  in  this  section  facilitate  interoperability 
between  C4ISR  systems  through  the  use  of  standardized  user  interfaces,  style  guides,  and  symbology. 

C4ISR.7.1  Nuclear  Command  and  Control  HCI 

The  HCI  standards  associated  with  Nuclear  Command  and  Control  address  all  the  usual  HCI  issues 
with  an  emphasis  on  system  safety  considerations. 

C4ISR.7.1(a)  Emerging.  This  section  contains  emerging  HCI  standards  applicable  to  Nuclear  C2 
systems. 

Standardized  HCI  for  all  EAM  injection  processors  will  reduce  training  requirements.  The  following 
standard  is  emerging: 

-  HMI  DIRECT  ICD,  “Human-Machine  Interface  (HMI)  Design  Criteria,”  CDRL  135C-  03,  V3.0, 

5  March  1999. 

C4ISR.8  Information  Security  Standards 

The  information  security  standards  and  profiles  described  in  this  section  facilitate  interoperability 
between  C4ISR  systems  through  the  use  of  standardized  security  interfaces  for  systems  that  process, 
transport,  model,  or  exchange  information. 

C4ISR.8(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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C4ISR.CRY:  Cryptologic  Subdomain 

C4ISR.CRY.1  Subdomain  Description 

The  Cryptologic  Subdomain  provides  the  high-level  foundation  and  guidance  for  interoperability  and 
seamless  flow  of  information  between  and  among  all  Cryptologic  Partners  and  systems  and  the 
associated  Military  components  in  a  collaborative  and  secure  environment.  It  promotes  interoperability 
with  other  components  of  the  U.S.  Intelligence  (IC)  and  foreign  Cryptologic  partners. 

C4ISR.CRY.2  Purpose  and  Scope 

The  Cryptologic  Subdomain  is  an  extension  of  the  JTA  and  is  based  on  certain  technical  foundations  for 
migrating  Cryptologic  systems  within  the  United  States  (USCS)  toward  a  common  Unified  Cryptologic 
System  (UCS)  architecture  as  directed  by  the  Director,  NSA  (DIRNSA)  and  the  Director,  Central 
Intelligence  (DCI).  The  migration  will  be  accomplished  through  the  use  of  mandated  standards  in  the 
JTA,  the  Unified  Cryptologic  Architecture — Technical  Architecture  (UCA-TA)  (January  1998),  the 
Maritime  Cryptologic  Architecture  (MCA)  Technical  View  (TV)  (version  2.1,  July  2001),  the  NRO 
Integrated  Overhead  SIGINT  Architecture  (IOSA)  (December  2001)  and  the  joint  Airborne  SIGINT 
Architecture  (JASA)  (version  1.0,  July  2000).  Additional  architectures  and  their  technical  views  arc 
under  development  by  other  Cryptologic  Partners. 

C4ISR.CRY.3  Applicability 

This  Subdomain  applies  to  all  National  and  Tactical  Cryptologic  systems,  subsystems  and 
demonstration  systems.  It  applies  to  all  new  acquisitions  and  upgrades  to  existing  systems  and 
subsystems.  For  the  purpose  of  this  Subdomain,  a  Cryptologic  system  is  defined  as  any  system  that 
collects,  processes,  analyzed,  disseminates  and/or  manages  Signal  Intelligence  (SIGINT)  and/or 
performs  SIGINT  related  information  assurance  services. 

C4ISR.CRY.4  Background 

Faced  with  the  challenges  of  keeping  pace  with  changing  intelligence  requirements,  budgetary 
uncertainty  and  technological  revolutions,  the  DIRNSA,  under  the  auspices  of  the  Deputy  Secretary  of 
Defense  and  the  DCI,  commissioned  the  Unified  Cryptologic  Architecture  (UCA)  study.  The  primary 
goal  of  the  UCA  study  was  to  provide  an  architecture  that  would  ensure  an  interoperable  and  secure 
USCS  by  2010.  The  result  of  the  study  was  the  introduction  of  the  UCA  Operational,  Systems  and 
Technical  Architectures.  Parallel  efforts  in  the  Cryptologic  community  led  to  the  development  of 
subordinate  architecture  views.  Some  of  the  subordinate  architectures  are  complementary  to  the  JTA 
and  will  be  used  in  conjunction  with  the  JTA  Core  and  JTA  C4ISR  Domain  by  all  members  of  the 
Cryptologic  community. 

The  current  status  of  the  Cryptologic  architectures  and  technical  views  is  this:  The  Cryptologic 
community  is  coordinating  and  vetting  the  mandatory  C4ISR  architecture  views  to  create  a  community 
approved  UCA  version  1.0  by  the  end  of  FY02.  Additional  views  will  be  developed  in  FY03.  The 
C4ISRTV-1  will  likely  be  delivered  in  FY03,  and  will  include  a  set  of  standards  common  to  the 
Cryptologic  community.  Configuration  management  will  begin  as  the  C4ISR  products  are  finished  and 
approved  by  the  community.  As  the  community  completes  an  approved  common  set  of  C4ISR  views, 
the  Cryptologic  Community  Partner  architectures  will  be  brought  into  concordance  with  the  approved 
UCA,  although  as  necessary  they  may  contain  more  detail  in  appropriate  areas  of  interest,  including 
additional  standards  in  the  technical  view. 
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C4ISR.CRY.5  Subdomain-Specific  Services  and  Interfaces 

The  following  section  presents  mandatory  and  emerging  standards  for  Cryptologic  Subdomain-specific 
services  and  interfaces. 

C4ISR.CRY.5.1  Small-Scale  Special  Purpose  Devices 

Some  cryptologic  processing  is  performed  using  Small-Scale  Special  Purpose  Devices  (SPDs)  that  may 
be  embedded  within  larger  host  systems  or  remotely  located  devices.  Cryptologic  systems  encompass 
both  real-time  and  non-real-time  SPDs.  The  communications  processing,  signal  processing,  and 
mathematical  analysis  are  performed  in  real-time  by  embedded  systems  that  require  speeds  at  least 
three  orders  of  magnitude  higher  than  traditional  C4I  systems.  Real-time  systems  also  require 
deterministic  scheduling  and  robust  fault  tolerance. 

C4ISR.CRY.5.1  (a)  Emerging.  CompactPCI  (cPCI)  is  a  competing  bus  standard  that  uses  the  same  form 
factor  as  VME  and  the  protocols  of  the  much  smaller  Peripheral  Component  Interconnect  (PCI) 
standard,  which  is  emerging  for  backplanes  and  circuit  cards. 

-  CompactPCI  (cPCi),  Version  1.0,  1996. 

C4ISR.CRY.5.2  Collaborative  Data  Sharing 

The  following  sections  address  mandatory  and  emerging  cryptologic  standards  for  transfer  of 
collaborative  data. 

C4ISR.CRY.5.2(a)  Emerging.  The  Common  Cryptologic  Data  Model  (CCDM)  and  Common 
Cryptologic  Data  Format  (CCDF)  Release  2.3,  6  July  2001,  represent  a  new  family  of 
metadata/formats  (implemented  in  XMF)  for  the  exchange  of  Cryptologic  data.  In  limited  use  today, 
CCDM/CCDF  was  approved  by  NSA/CSS  Enterprise  Standards  Program  -  Standards  Board  as  an 
NSA/CSS  standard  in  January  2001  and  is  emerging  as  the  Cryptologic  community  standard  for 
collaborative  data  sharing  functions: 

-  The  Common  Cryptologic  Data  Model  (CCDM)  and  Common  Cryptologic  Data  Format 

(CCDF),  Release  2.3,  6  July  2001 . 
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C4ISR.SR.1  Subdomain  Introduction 

The  purpose  of  the  Space  Reconnaissance  (SR)  Subdomain  (SRS)  of  the  C4ISR  Domain  is  to  identify 
the  minimum  set  of  technical  standards  for  interfaces  among  SR  information  technology  (IT)  systems, 
and  between  those  systems  and  other  Department  of  Defense  (DoD)  systems.  The  standards  contained 
here  are  in  addition  to  those  applicable  standards  found  in  the  C4ISR  Domain  and  in  the  JTA  Core. 

The  scope  of  the  SRS  includes  space-related  functions  unique  within  the  JTA.  The  SRS  identifies 
additional  standards  that  arc  unique  to  SR  communications  and  data  processing.  Standards  not  unique 
to  SR  are  contained  in  the  C4ISR  Domain  or  in  the  JTA  Core. 

The  SRS  applies  to  acquisitions  of  new  and  upgraded  SR  IT  systems,  as  well  as  advanced  technology 
demonstrations.  The  standards  mandated  in  the  JTA  Core,  C4ISR  Domain,  and  SRS  are  all  applicable 
to  the  external  SR  IT  interfaces. 

The  SRS  is  developed  and  maintained  by  the  SRS  Working  Group  (SRS  WG)  under  the  auspices  and 
procedures  of  the  JTA  Development  Group  (JTADG).  The  SRS  WG  is  chaired  by  the  National 
Reconnaissance  Office  (NRO). 

C4ISR.SR.2  Information  Processing  Standards 

This  section  identifies  standards  for  interoperability  among  SR  IT  and  other  DoD  Intelligence, 
Surveillance,  &  Reconnaissance  (ISR)  systems  in  addition  to  the  standards  cited  in  the  JTA  Core 
Section  2  and  C4ISR  Domain  C4ISR.4. 

C4ISR.SR.2.1  Hardware  Product  Data  Interchange 

Hardware  product  data  interchange  defines  the  service  for  transmitting  computer  aided  data  that 
describes  parts,  geometry,  arrangement,  construction,  connectivity,  manufacturing,  assembly, 
integration,  maintenance,  or  operation  of  component,  subsystems  or  systems.  This  product  data  may  be 
used  in  Computer  Aided  Design  (CAD),  Computer  Aided  Manufacturing  (CAM),  or  Computer  Aided 
Engineering  (CAE),  which  are  collectively  referred  to  as  CAx. 

C4ISR.SR.2.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.SR.2.2  Object-Oriented  Database  Management 

This  service  supports  the  definition,  design,  storage,  and  retrieval  of  data  elements  managed  by 
commercial  or  custom-developed  object-oriented  database  management  systems. 

C4ISR.SR.2.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.SR.3  Information  Transfer  Standards 

Information  transfer  standards  arc  used  to  disseminate  National  and  Tactical  intelligence  information  to 
Joint  service  tactical  units.  This  section  identifies  interface  standards  required  for  interoperability 
between  SR  IT  and  other  DoD  Intelligence,  Surveillance,  &  Reconnaissance  (ISR)  systems  in  addition 
to  the  standards  cited  in  the  JTA  Core  Section  3  and  C4ISR  Domain  C4ISR.5. 

C4ISR.SR.3.1  Synchronous  Optical  Network  Transmission  Facilities 

In  addition  to  standards  contained  in  3.7.4  of  the  JTA  Core,  the  following  standard  applies  to  SR 
communication  systems  that  use  Synchronous  Optical  Network  (SONET). 
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C4ISR.SR.3.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

C4ISR.SR.4  Information  Modeling,  Metadata,  and  Information  Exchange  Standards 

The  U.S.  Electronic  Intelligence  (ELINT)  establishes,  defines,  and  explains  the  reporting  format  and 
promulgation  of  data  formats  and  codes  for  reducing  ELINT  intercept  data  to  processing  media 
(magnetic  data  tape,  punch  card,  or  punched  paper  tape). 

C4ISR.SR.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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CS.1  Domain  Description 

The  Combat  Support  Domain  addresses  those  specific  elements  necessary  for  the  production,  use,  or 
exchange  of  information  within  and  among  systems  supporting  personnel,  logistics,  and  other  functions 
required  to  maintain  operations  or  combat.  The  Combat  Support  Domain  consists  of  automated  systems 
that  perform  combat  service  support  and  administrative  business  functions,  such  as  acquisition,  finance, 
human  resources  management,  legal,  logistics,  transportation,  and  medical  functions.  As  illustrated  in 
Figure  1-2,  the  domain  has  four  subdomains:  Automatic  Test  Systems  (CS.ATS),  Defense 
Transportation  System  (CS.DTS),  Fluman  Resources  (CS.HR),  and  Medical  (CS.MED).  This  domain 
uses  the  Technical  Reference  Model  (TRM)  cited  in  L8  of  the  JTA  as  its  framework.  Combat  Support 
Application  Platform  Entity  service  areas  are  addressed  in  CS.2  as  additions  to  the  JTA  Core. 
Additional  Application  Software  Entity  service  areas  required  to  support  Combat  Support  Domain 
systems  are  addressed  in  CS.5.2  as  domain- specific  service  areas. 

CS.2  Purpose  and  Scope 

The  Combat  Support  Domain  has  been  developed  to  integrate  agile  combat  support  elements  and  other 
domains  with  a  common  technical  architecture  for  information  exchange.  The  goals  for  the  Combat 
Support  Domain  are:  1)  to  improve  applications  interoperability,  promote  improved  business  practices, 
and  reduce  operations  costs  within  the  Combat  Support  Domain,  and  2)  to  improve  interoperability  and 
increase  combat  support  information  access  with  C4ISR  systems.  The  Combat  Support  Domain 
embraces  the  principles  established  in  the  JTA  Core.  Only  those  paragraphs  from  the  Core  that  have 
additions  are  included  in  this  domain. 

CS.3  Applicability 

The  Combat  Support  Domain  identifies  standards  applicable  to  Department  of  Defense  (DoD)  Combat 
Support  elements,  e.g.,  Logistics,  Electronic  Data  Interchange  (EDI),  Continuous  Acquisition  and 
Life-Cycle  Support  (CALS),  Medical,  and  Transportation. 

CS.4  Background 

There  are  numerous  information  technology  services  that  support  warfighter  activities.  These  services 
need  to  be  interoperable  with  the  rest  of  the  DoD  community. 

CS.5  Core-Related  Information  Technology  Categories 

In  addition  to  the  standards  found  in  the  JTA  Core,  the  Combat  Support  Domain  includes  additional 
standards  in  the  following  document  and  data  interchange,  and  information  exchange  service  areas. 

CS.5.1  Document  Interchange 

CALS  has  developed  a  set  of  standards  that  apply  to  this  service  area.  CALS  Standard  Generalized 
Markup  Language  (SGML)  profiles  the  standard  ISO  8879  by  selecting  a  particular  Document  Type 
Definition  (DTD)  and  other  parameters  that  help  standardize  the  development  of  technical  manuals  for 
DoD.  CALS  also  developed  a  handbook  for  applying  CALS  SGML  (MIL-F1DBK-28001, 

30  June  1995).  Although  Hypertext  Markup  Language  (HTML)  is  also  a  subset  of  SGML,  it  is  not 
sufficiently  robust  enough  for  Technical  Manual  (TM)/  Technical  Order  (TO)  development.  (Extensible 
Markup  Language  [XML]  may  replace  both  CALS  SGML  and  HTML  in  the  future.)  CALS  also  has  a 
standard  for  archiving  documents  (MIL-STD-1840C). 

CS.5.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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CS.5.2  Graphics  Data  Interchange 

CALS  has  developed  a  metadata  standard,  MIL-PRF-28003B,  which  profiles  the  ISO  Computer 
Graphics  Metafile  (CGM)  standard  (ISO  8632).  Also,  a  CALS  Raster  Standard,  MIL-PRF-28002C, 
puts  raster  graphics  into  a  binary  format. 

CS.5.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.5.3  Product  Data  Interchange 

Several  standards  exist  for  exchanging  product  data.  The  ANSI/US  PRO/IPO- 100- 1996  and 
MIL-PRF-28000B  standards  define  a  neutral  data  format  that  allows  the  digital  exchange  of 
information  between  Computer-Aided  Design  (CAD)  and  Computer-Aided  Manufacturing 
(CAD/CAM)  systems.  ANSI/US  PRO- 100- 1996  supports  digital  design  and  manufacturing 
information  about  an  object  sufficient  to  support  manufacturing  and  construction  only. 
MIL-PRF-28000B  contains  applications  subsets  and  protocols  that  form  profiles  of  IGES  Version  5.3. 

CS.5.3(a)  Emerging.  The  following  standards  arc  emerging  for  use  in  building  a  ship: 

-  ISO  10303-203:1994,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  203:  Application  protocol:  Configuration  controlled  design, 
with  Amendment  1 :2000. 

-  ISO/DIS  10303-204:2002,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  204:  Application  Protocol:  Mechanical  design  using 
boundary  representation. 

-  ISO  10303-207:1999,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  207:  Application  Protocol:  Sheet  metal  die  planning  and 
design  with  Technical  Corrigendum  1:2001. 

-  ISO  10303-209:2001,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  209:  Application  Protocol:  Composite  and  metallic 
structural  analysis  and  related  design. 

-  ISO  10303-210:2001 ,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  210:  Application  Protocol:  Electronic  assembly, 
interconnection,  and  packaging  design. 

-  ISO  10303-214:2001,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  214:  Application  Protocol:  Core  data  for  automotive 
mechanical  design  processes. 

-  ISO/CD  10303-215,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  Part:  215  Application  Protocol:  Ship  Arrangements. 

13  November  2001. 

-  ISO/CD  10303-218,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  Part:  21 8  Application  Protocol:  Ship  Structures,  28  August  2001 . 

-  ISO  10303-225:1999,  Industrial  automation  systems  and  integration  -  Product  data 
representation  and  exchange  -  Part  225:  Application  Protocol:  Building  elements  using  explicit 
shape  representation. 

Effective  use  of  Standard  for  the  Exchange  of  Product  Data  Model  (STEP)  to  share  product  model  data 
for  systems  requires  a  companion  standard,  ISO/IEC  13584,  to  exchange  CAD  Part  Libraries  (PLIB). 
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The  PLIB  supplies  a  data  model  of  the  supplier  part  library,  supplier  identification,  and  part  geometry. 
The  following  standards  are  emerging: 

-  ISO/I  EC  13584-20:1998,  Industrial  automation  systems  and  integration  -  Parts  library  - 
Part  20:  Logical  resource:  Logical  model  of  expressions. 

-  ISO/I  EC  13584-42:1998,  Industrial  automation  systems  and  integration  -  Parts  library  - 
Part  42:  Description  methodology:  Methodology  for  structuring  part  families. 

CS.5.4  Electronic  Data  Interchange 

Electronic  Data  Interchange  (EDI)  is  a  Base  Service  Area  specializing  in  the  computer-to-computer 
exchange  of  business  information  using  a  public  standard.  EDI  is  a  central  part  of  Electronic  Commerce 
(EC),  the  paperless  exchange  of  business  information.  FIPS  PUB  161-2  establishes  the  Federal  EDI 
Standards  Management  Coordinating  Committee  (FESMCC)  to  harmonize  the  development  of  EDI 
transaction  sets  and  message  standards  among  Federal  agencies,  and  the  adoption  of  Government-wide 
implementation  conventions.  The  Federally  approved  Implementation  Conventions  may  be  viewed  on 
the  Web  at  http://snad.ncsl.nist.gov/dartg/edi/fededi.html. 

The  DoD  EDI  Standards  Management  Committee  (EDISMC)  was  established  to  coordinate  EDI 
standardization  activities  within  DoD.  The  EDISMC  supports  the  development,  adoption,  publication, 
and  configuration  management  of  EDI  implementation  conventions  for  DoD.  The  DoD  EDISMC 
manages  the  efforts  of  several  Functional  Working  Groups  (FWGs).  DoD  FWGs  have  been  established 
in  the  following  areas:  Logistics,  Finance,  Healthcare,  Transportation,  Procurement,  and 
Communication,  Command,  and  Control.  EDISMC-approved  implementation  conventions  may  be 
submitted  to  the  FESMCC  for  approval  as  Federal  implementation  conventions.  Not  all  DoD  ICs  are 
submitted  to  the  FESMCC  for  Federal  approval.  For  more  information,  visit  the  Web  site  at: 
http://www-edi.itsi.disa.mil. 

FIPS  PUB  161-2,  22  May  1996,  Electronic  Data  Interchange  (EDI)  adopts,  with  specific  conditions, 
ANSI  ASC  X12,  UN/EDIFACT,  and  ANSI  HL7.  HL7  can  be  found  in  Combat  Support  Medical 
Subdomain. 

CS. 5.4(a)  Emerging.  The  following  standards  are  emerging: 

-  ISO  9735-1 :1 988,  Electronic  data  interchange  for  administration,  commerce  and  transport 
(EDIFACT)  -  Application  level  syntax  rules  (Syntax  version  number  4)  -  Part  1 :  Syntax  rules 
common  to  all  parts. 

-  ISO  9735-2:1998,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  2:  Syntax 
rules  specific  to  batch  EDI. 

-  ISO  9735-3:1998,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  3:  Syntax 
rules  specific  to  interactive  EDI. 

-  ISO  9735-4:1998,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  4:  Syntax 
and  service  report  message  for  batch  EDI. 

-  ISO  9735-5:1999,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  5:  Security 
rules  for  batch  EDI  (authenticity,  integrity  and  non-repudiation  of  origin). 

-  ISO  9735-6:1999,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  6:  Secure 
authentication  and  acknowledgement  message  (message  type  -  AUTACK). 

-  ISO  9735-7:1999,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  7:  Security 
rules  for  batch  EDI  (confidentiality). 
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-  ISO  9735-8:1998,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  8: 
Associated  data  in  EDI. 

-  ISO  9735-9:1999,  Application  level  syntax  rules  (Syntax  version  number:  4)  -  Part  9:  Security 
key  and  certificate  management  message  (message  type  -  KEYMAN). 

CS.5.5  Information  Modeling,  Metadata,  and  Information  Exchange  Standards 

This  section  specifies  additional  information  modeling,  metadata,  and  information  exchange  standards 
that  pertain  to  the  DoD  Combat  Support  Elements. 

CS.5.5. 1  Electronic  Fingerprint  Information  Exchange  Standards 

The  electronic  exchange  of  fingerprint  information  with  automated  fingeiprint  identification  and 
analysis  systems  requires  fingerprints  to  be  electronically  captured  to  image-quality  standards  and  to  be 
formatted  and  documented  in  standard  formats  that  are  essential  to  interoperability. 

CS.5.5. 1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.5.6  Information  Security  Standards 

EC/EDI  have  security  services  associated  with  ANSI  ASC  X12  transactions.  ANSI  ASC  X12.58  is  a 
description  of  that  security  but  is  not  mandated. 

CS.5.6(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.6  Domain-Specific  Standards 

This  section  contains  additional  Application  Software  Entity  service  areas  required  to  support  Combat 
Support  Domain  Systems. 

CS.6.1  Electronic  Business/Electronic  Commerce 

The  Electronic  Business/Electronic  Commerce  (EB/EC)  Section  provides  standards  useful  for  any  DoD 
effort  involved  in  electronic  business  operations.  DoD  needs  to  take  full  advantage  of  the  significant 
process  improvement  and  reengineering  opportunity  available  through  the  implementation  of  EB/EC 
concepts  and  technology.  EB/EC  within  DoD  can  support  a  variety  of  areas,  including  Finance, 
Procurement,  Logistics,  Personnel,  Medical,  Transportation,  and  Acquisition  functions. 

CS.6. 1.1  Smart  Card  Technology  Standards 

Smart  Card  standards  are  derived  from  identification  card  standards  and  detail  the  physical,  electrical, 
mechanical,  and  application  programming  interface.  ISO  7816  series  is  for  contact  Smart  Cards.  Smart 
Card  standards  are  essential  for  interoperability  between  multivendor  cards  and  readers. 

CS.6. 1.1  (a)  Emerging.  The  standards  for  both  contact  and  contactless  Smart  Cards  are  still  evolving 
and  being  specified.  ISO  7816  series  is  for  contact  Smart  Cards  while  ISO  14443  and  15693  specify  the 
standards  for  various  types  of  contactless  Smart  Cards.  The  following  Smart  Card  standards  are 
emerging: 

-  ISO/IEC  7816-8:1999,  Identification  cards  -  Integrated  circuit(s)  card  with  contacts  -  Part  8, 
Security  architecture  and  related  interindustry  commands. 

-  ISO/IEC  7816-9:2000,  Identification  cards  -  Integrated  circuit(s)  card  with  contacts  -  Part  9: 
Enhanced  interindustry  commands. 

-  ISO/IEC  7816-10:1999,  Identification  cards  -  Integrated  circuit(s)  card  with  contacts  -  Part  1 0: 
Electronic  signals  and  answer  to  reset  for  synchronous  cards. 
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-  ISO/IEC  CD  7816-11 :2000,  Identification  cards  -  Integrated  circuit(s)  card  with  contacts  - 
Part  11:  Personal  verification  through  biometric  methods  in  integrated  circuit  cards. 

-  ISO/IEC  CD  7816-15:2000,  Identification  cards  -  Integrated  circuit(s)  card  with  contacts  - 
Part  15:  Cryptographic  information  application. 

-  ISO/IEC  15693-1:2000,  Identification  cards  -  Contactless  integrated  circuit(s)  -  Vicinity 
cards  -  Part  1 :  Physical  characteristics. 

-  ISO/IEC  15693-2:2000,  Identification  cards  -  Contactless  integrated  circuit(s)  -  Vicinity 
cards  -  Part  2:  Air  interface  and  initialization,  with  Technical  Corrigendum  1 :2001 . 

-  ISO/IEC  15693-3:2001,  Identification  cards  -  Contactless  integrated  circuit(s)  -  Vicinity 
cards  -  Part  3:  Anticollision  and  transmission  protocol. 
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CS.ATS:  Automatic  Test  Systems  Subdomain 

CS.ATS.1  Subdomain  Description 

An  Automatic  Test  System  (ATS)  has  three  major  components:  Automated  Test  Equipment  (ATE),  Test 
Program  Sets  (TPSs),  and  the  Test  Environment.  The  ATE  consists  of  test  and  measurement 
instruments,  a  host  computer,  switching,  communication  buses,  a  receiver,  and  system  software.  The 
host  computer  controls  the  test  and  measurement  equipment  and  execution  of  the  TPS.  The  system 
software  controls  the  test  station  and  allows  TPSs  to  be  developed  and  executed.  Examples  of  system 
software  include  operating  systems,  compilers,  and  test  executives.  The  TPS  consists  of  software  to 
diagnose  Units  Under  Test  (UUTs),  a  hardware  fixture  that  connects  the  UUT  to  the  ATE,  and 
documentation  that  instructs  the  station  operator  on  how  to  load  and  execute  the  TPS.  The  Test 
Environment  includes  a  description  of  the  ATS  Architecture,  programming  and  test  specification 
languages,  compilers,  development  tools,  a  standard  format  for  describing  UUT  design  requirements, 
and  test  strategy  information  that  allows  TPS  software  to  be  produced  at  a  lower  cost.  A  high-level 
overview  of  a  typical  ATS  is  shown  in  Figure  CS.ATS- 1. 
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Figure  CS.ATS-1:  Generic  ATS  Architecture 


CS.ATS.2  Purpose 

The  puipose  of  the  ATS  Subdomain  is  to: 

□  Provide  the  foundation  for  a  seamless  flow  of  information  and  interoperability  among  all 
Department  of  Defense  (DoD)  ATS. 

□  Mandate  standards  and  guidelines  for  system  development  and  acquisition  that  will 
significantly  reduce  cost,  development  time,  and  fielding  time  for  improved  systems,  while 
minimizing  the  impact  on  program  performance  wherever  possible. 

□  Improve  the  test  acquisition  process  by  creating  an  ATS  framework  that  can  meet  functional 
and  technical  needs,  promote  automation  in  software  development,  and  the  re-hostability  and 
portability  of  TPSs. 

□  Communicate  to  industry  DoD’s  intention  to  use  open  systems  products  and  implementations. 
DoD  will  buy  commercial  products  and  systems  that  use  open  standards  to  obtain  the  most 
value  for  limited  procurement  dollars. 

CS.ATS.3  Applicability 

The  following  factors  guided  the  selection  of  interfaces  in  the  ATS  Subdomain. 

□  Hardware  and  Software  -  Hardware  and  software  associated  with  the  supported  test  domains 
and  software  interfaces  required  to  build  ATS  were  included. 

□  Signal  Types  -  The  scope  was  limited  to  digital,  analog,  Radio  Frequency  (RF),  and  microwave 
electrical  signals. 
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□  Testing  Levels  -  The  interface  standards  in  the  ATS  Subdomain  are  mandated  for  factory, 
depot,  intermediate,  and  operational/organizational  levels  of  ATS. 

The  standards  selected  for  inclusion  in  the  ATS  Subdomain  were  found  to  be  key  for  the  generic, 
open  system  architecture  of  ATSs.  The  standards  are  based  on  commercial,  open  system  technology, 
have  implementations  available,  and  are  strongly  supported  in  the  commercial  marketplace.  Standards 
in  the  ATS  Subdomain  meet  the  following  criteria: 

□  Availability  -  The  standards  arc  currently  available. 

□  Commercial  Acceptance  -  The  standards  arc  used  by  several  different  commercial  concerns. 

□  Efficacy  -  The  standards  increase  the  interoperability  of  ATS  hardware  and  software. 

□  Openness  -  Mandated  standards  are  all  open,  commercial  standards. 

Standards  that  arc  commercially  supported  in  the  marketplace  with  validated  implementations  available 
in  multiple  vendors’  mainstream  commercial  products  took  precedence  over  other  standards.  Publicly 
held  standards  were  generally  preferred.  International  or  national  industry  standards  were  preferred 
over  military  or  other  Government  standards.  Many  standards  have  optional  parts  or  parameters  that 
can  affect  interoperability.  In  some  cases,  a  standard  may  be  further  defined  by  a  standards  profile, 
which  requires  certain  options  to  be  present  to  ensure  proper  operation  and  interoperability. 

Previously,  each  of  the  Services  had  established  its  own  sets  of  standards  (e.g.,  technical  architectures). 
The  ATS  Subdomain  is  envisioned  as  a  single,  generic,  open  system  architecture  in  DoD  ATS.  The  ATS 
Subdomain  shall  be  used  by  anyone  involved  in  the  management,  development,  or  acquisition  of  new 
or  improved  ATSs  within  DoD.  System  developers  shall  use  the  ATS  Subdomain  to  ensure  that  new  and 
upgraded  ATSs,  and  the  interfaces  to  such  systems,  meet  interoperability  requirements.  System 
integrators  shall  use  this  document  to  facilitate  the  integration  of  existing  and  new  systems.  Operational 
requirements  developers  shall  be  cognizant  of  the  ATS  Subdomain  in  developing  requirements  and 
functional  descriptions.  ATS  is  a  subdomain  of  the  Combat  Support  Domain  of  the  JTA. 

CS.ATS.4  Background 

From  1980  to  1992,  DoD’s  investment  in  depot  and  factory  ATSs  exceeded  $35  billion  with  an 
additional  $15  billion  for  associated  support.  Often,  application-specific  test  capability  was  procured  by 
weapon  systems  acquisition  offices  with  little  coordination  among  DoD  offices.  This  resulted  in  a 
proliferation  of  different  custom  equipment  types  with  unique  interfaces  that  made  DoD  appear  to  be  a 
variety  of  separate  customers.  To  address  this  problem,  DoD  enacted  policy  changes  requiring  that 
“Automatic  Test  System  capabilities  be  defined  through  critical  hardware  and  software  elements.”  In 
response,  the  joint  service  Automatic  Test  Systems  (ATS)  Research  and  Development  (R&D) 
Integrated  Product  Team  (IPT),  known  as  ARI,  has  worked  toward  the  definition  of  an  ATS  architecture 
based  on  open  system  principles.  A  summary  of  the  ARI’s  work  is  presented  in  this  subdomain.  The 
ATS  Subdomain  will  aid  in  satisfying  the  requirements  of  DoD  Regulation  5000.2-R  to  migrate 
DoD-designated  tester  families  toward  a  common  architecture.  The  policy  changes  listed  below  require 
DoD  offices  to  take  a  unified  corporate  approach  to  acquisition  of  ATSs. 

□  DoD  Regulation  5000.2-R,  Mandatory  Procedures  for  Major  Defense  Acquisition  Programs 
and  Major  Automated  Information  System  Acquisition  Programs,  paragraph  4. 3. 3.4, 

March  15,  1996,  brings  a  cost-effective  approach  to  the  acquisition  of  ATS.  This  policy 
requires  hardware  and  software  needs  for  depot-  and  intermediate-level  applications  to  be  met 
using  DoD-designated  families  and  commercial  equipment  with  defined  interfaces  and  requires 
the  management  of  ATS  as  a  separate  commodity  through  a  DoD  Executive  Agent  Office 
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(EAO).  The  policy  also  requires  that  the  introduction  of  unique  types  of  ATS  into  DoD  field, 
depot,  and  manufacturing  operations  be  minimized.  Change  3  of  DoD  5000.2-R,  dated 
March  23,  1998,  requires  that  the  ATS  selection  “shall  be  based  on  a  cost  and  benefit  analysis 
that  ensures  that  the  ATS  chosen  is  the  most  beneficial  to  the  DoD  over  the  system  life  cycle.” 

□  Secretary  of  Defense  Memorandum  on  Specifications  and  Standards,  29  June  1994,  directs  that 
DoD  procurements  be  made  first  by  performance  definition,  second  by  commercial  standards, 
and  finally  (and  only  with  waiver)  by  military  standards. 

The  use  of  open  standards  in  ATSs  has  been  projected  to  provide  the  following  five  benefits.1 * 3 

□  Improve  the  test  acquisition  process  by  creating  an  ATS  framework  that  can  meet  functional 
and  technological  needs,  and  promote  automation  in  so  it  ware  development,  re-hostability,  and 
portability  of  TPSs. 

□  Decrease  the  use  of  custom  hardware  from  approximately  70  percent  today  to  30  percent. 

□  Reduce  engineering  costs  70  percent. 

□  Reduce  TPS  integration  time  and  cost  50  to  75  percent. 

□  Provide  an  iterative  improvement  in  the  quality  of  test  by  the  reuse  and  refinement  of  libraries. 

CS.ATS.5  Core-Related  Information  Technology  Categories 

The  standards  in  the  ATS  Subdomain  apply  in  addition  to  the  standards  in  the  Combat  Support  Domain 
(standards,  interfaces,  and  service  areas)  and  the  JTA  Core.  These  additions  arc  common  to  the  majority 
of  ATSs  and  support  the  functional  requirements  of  these  systems. 

CS.ATS.5. 1  Data  Interchange  Services 

This  section  identifies  data  interchange  services  required  by  the  ATS  in  addition  to  the  standards  cited 
in  the  JTA  Core  and  Combat  Support  Domain. 

CS.ATS.5. 1.1  Instrument  Driver  API  Standards 

The  Instrument  Driver  Application  Programming  Interface  (DRV)  is  the  interface  between  the  generic 
instrument  class  serving  the  test  procedure  and  the  instrument  driver.  The  calls  made  available  at  this 
interface  include  calls  oriented  to  software  housekeeping,  such  as  initializing  the  driver  itself;  and  calls 
that  cause  the  instrument  to  perform  a  function,  such  as  arm  and  measure  commands.  The  service 
requests  crossing  this  interface  arc  communications  between  generic  ATS  assets  (e.g.,  digital 
multimeter)  and  specific  ATS  assets  (e.g.,  vendor  XYZ  model  123  digital  multimeter).  The  instruments 
arc  ATS  assets,  but  the  calls  to  the  driver  arc  either  direct  or  close-to-direct  consequences  of  action 
requests  in  the  Test  Procedure,  which  is  a  TPS  asset.  Some  instrument  functions  arc  available  from  a 
variety  of  instruments.  However,  the  driver  calls  to  access  these  functions  vary  from  instrument  to 
instrument.  This  interferes  with  TPS  portability.  Historically,  cross-platform  incompatibilities — in  the 
way  drivers  for  the  same  instrument  implement  the  same  function — have  been  a  recurring  ATS 
integration  problem.  In  common  commercial  practice,  the  driver  is  acquired  with  the  instrument  from 
the  instrument’s  original  equipment  manufacturer.  The  DRV  API  interface  allows  software  developed 
by  different  organizations  to  work  together. 

CS.ATS.5. 1.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 


1  Institute  for  Defense  Analysis  (IDA)  Investment  Strategy  Study.  Alexandria,  VA:  Institute  for  Defense  Analysis  (IDA),  1993. 
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CS.ATS.5.1.2  Digital  Test  Data  Formats 

Digital  Test  Data  Formats  (DTFs)  describe  the  sequence  of  logic  levels  necessary  to  test  a  digital  UUT. 
Digital  test  data  is  generally  divided  into  four  parts:  patterns,  timing,  levels,  and  circuit  models  and 
component  models  used  for  the  fault  dictionary.  In  addition,  certain  diagnostic  data  may  exist  that  is 
closely  associated  with  the  digital  test  data.  This  interface  is  intended  to  be  used  for  capturing  the  output 
of  digital  automatic  test  pattern  generators.  A  standard  for  describing  DTF,  known  as  Logic  Automated 
Stimulus  and  Response  (LASAR)  Teradyne  ASCII  Postprocessor  (TAP)  (LSRTAP),  has  become  a  de 
facto  industry  standard. 

CS.ATS.5. 1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.ATS.5.1.3  Resource  Adapter  Interface 

The  Resource  Adapter  Interface  (RAI)  provides  a  generic  method  for  obtaining  instrumentation 
services.  These  services  isolate  TPSs  from  test  instruments  by  allowing  test  requirements  to  be 
described  in  TPSs  rather  than  instrument-specific  functions  or  commands  that  would  tie  TPSs  to 
specific  instruments.  The  RAI  makes  it  easier  to  interchange  instruments  and  instrument  drivers,  and 
allows  virtual  instruments  to  be  developed.  DoD  is  working  with  industry  consortiums  such  as  the 
VXI  plug  &  play  Systems  Alliance  and  the  Interchangeable  Virtual  Instruments  Foundation  to  develop 
a  common  solution. 

CS.ATS.5. 1.3(a)  Emerging.  The  following  standards  are  emerging: 

-  VPP-3.1 ,  VXI  plug  &  play  Systems  Alliance:  Instrument  Drivers  Architecture  and  Design 
Specification,  Revision  4.1, 4  December  1998. 

-  VPP-3.2,  VXI  plug  &  play  Systems  Alliance:  Instrument  Driver  Functional  Body  Specification, 
Revision  5.0,  4  December  1998. 

-  VPP-3.3,  VXI  plug  &  play  Systems  Alliance:  Instrument  Driver  Interactive  Developer  Interface 
Specification,  Revision  4.01,  13  December  2001 . 

-  VPP-3.4,  VXI  plug  &  play  Systems  Alliance:  Instrument  Driver  Programmatic  Developer 
Interface  Specification,  Revision  2.3,  17  March  2000. 

Emerging  Interchangeable  Virtual  Instruments  (IVI)  Foundation  Standards  are  the  following: 

-  IVI-4.1 :  IviScope  Class,  Revision  3.0,  4  April  2002. 

-  IVI-4.2:  IviDmm  -  Digital  Multimeter  Class,  Revision  3.0,  8  March  2002. 

-  IVI-4.3:  IviFGen  -  Function  Generator/Arbitrary  Waveform  Generator  Class,  Revision  3.0, 

18  December  2002. 

-  IVI-4.4:  IviDCPwr  Class  Specification,  Revision  2.0,  April  2002. 

-  IVI-4.6:  IviSwitch  Class  Specification,  Revision  3.0,  April  2002. 

-  IVI-4.7:  IviPwrMeter  Class  Specification,  Revision  1 .0,  April  2002. 

-  IVI-4.8:  IviSpecAn  Class  Specification,  Revision  1 .0,  April  2002. 

-  IVI-4.10:  IviRFSigGen  Class  Specification,  Revision  1 .0,  March  2002. 

CS.ATS.5. 1.4  Diagnostic  Processing  Standards 

The  diagnostic  processing  interface  resides  between  the  test  procedure  or  runtime  services  supporting 
the  TPS  and  a  diagnostic  reasoner,  diagnostic  controller,  or  other  diagnostic  process.  Diagnostic  tools 
are  most  frequently  encountered  in  one  of  three  forms:  expert  systems,  decision-tree  systems,  and 
model-based  reasoners.  Other  diagnostic  tools  are  expert  systems  known  as  the  Fault  Isolation  System 
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and  the  Expert  Missile  Maintenance  Advisor;  decision-tree  systems  including  Weapon  System 
Testability  Analyzer,  System  Testability  and  Maintenance  Program,  System  Testability  Analysis  Tool, 
and  AUTOTEST;  and  model-based  reasoners  including  Intelligent-Computer- Aided  Test,  Portable 
Interactive  Troubleshooter,  Artificial-Intelligence  Test,  and  Adaptive  Diagnostic  System. 

Standardization  in  this  area  would  allow  tools  to  be  written  that  can  translate  test  strategy  information 
to  various  test  programming  languages.  Additionally,  the  tools  would  be  interchangeable  since  one 
could  use  any  tool  to  obtain  the  same  output  source  code. 

CS.ATS.5. 1.4(a)  Emerging.  The  following  standards  are  emerging: 

-  IEEE  1232-2002,  Artificial  Intelligence  Exchange  and  Service  Tie  to  All  Test  Environments 
(AI-ESTATE)  Overview  and  Architecture. 

-  IEEE  1232.1-1997,  Trial  Use  Standard  for  AI-ESTATE  Data  and  Knowledge  Specification. 

-  IEEE  1232.2-1998,  Trial  Use  Standard  for  AI-ESTATE  Service  Specification. 

CS.ATS. 5. 1.5  Test  Requirements  Data  Standards 

High  re-host  costs  in  the  past  have  been  associated  with  the  failure  to  record  or  preserve  the 
signal-oriented  action  capabilities  as  required  as  opposed  to  as  used.  This  problem  is  most  visible  in  the 
allocation  phase  of  TPS  development.  When  a  TPS  is  transported  or  re-hosted,  the  resources  requested 
by  the  TPS  must  be  allocated  to  assets  in  the  target  ATS.  This  task  would  be  simplified  if  UUT  test 
requirements  were  available  in  the  form  of  load  specifications,  measurement  requirements,  and  stimuli 
requirements  that  must  appear  at  the  UUT  interface. 

CS.ATS. 5. 1.5(a)  Emerging.  The  following  standard  is  emerging: 

-  IEEE  Computer  Society  Test  Technology  Technical  Committee,  Test  Requirements  Model 
(TeRM). 

CS.ATS.6  Information  Transfer  Standards 

This  section  identifies  information  transfer  standards  required  by  the  ATS  in  addition  to  the  standards 
cited  in  the  JTA  Core  and  Combat  Support  Domain. 

CS.ATS.6. 1  Instrument  Communication  Manager  Standards 

The  Instrument  Communication  Manager  (ICM)  interface  includes  bus-specific  options  for 
communicating  from  the  instrument  driver  to  a  supporting  input/output  (EO)  library.  Until  recently, 
vendors  of  IEEE-488  and  VXI  bus  hardware  provided  software  drivers  for  their  buses  that  were 
different  according  to  the  hardware  bus  protocol  or  operating  system  (OS)  used.  This  situation 
interfered  with  the  plug-and-play  capabilities  that  users  thought  they  were  going  to  get  from  buying 
different  instruments  that  all  communicated  by  common  hardware  protocols.  The  same  functions  of  the 
same  instruments  were  not  accessed  through  software  in  the  same  way  across  buses  and  host  platforms. 
Different  manufacturers  of  IEEE-488  cards  had  proprietary  and  unique  software  calls.  Furthermore, 
Hewlett-Packard  and  National  Instruments — the  two  leading  vendors  of  VXI  Slot  0  cards  and 
embedded  controllers — used  different  I/O  calls  to  access  instruments.  This  impeded  the  transporting  of 
instrument  drivers,  Application  Development  Environments  (ADEs),  and  test  programs  from  one  set  of 
hardware  to  another.  Without  a  standard  ICM  interface,  vendors  cannot  provide  interoperable  or 
portable  instrument  drivers  because  different  vendors  would  use  different  I/O  drivers  at  the  very  lowest 
layer  of  the  software.  This  forces  instrument  drivers  to  be  tailored  to  specific  I/O  calls  for  each  test 
station  and  lowers  the  likelihood  that  instrument  drivers  will  be  commercially  available  for  each 
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configuration.  In  addition,  standard  I/O  software  allows  one  to  place  parameters  such  as  bus  addresses 
and  instrument  addresses  in  the  instrument  driver  instead  of  the  test  program. 

A  standard  ICM  interface  enables  higher-level  software  to  be  interoperable  and  portable  between 
vendors  and  across  different  platforms.  This  improves  the  interoperability  of  test  software  and  the 
ability  to  re-host  test  software  from  one  test  system  to  another. 

CS.ATS.6.1(a)  Emerging.  The  following  standard  is  emerging: 

-  VPP-4.3,  VXI  plug  &  play  (VPP)  Systems  Alliance  Virtual  Instrument  Standard  Architecture 
(VISA)  Library,  Revision  2.2,  17  March  2000. 

CS.ATS.6.2  Maintenance  Test  Data  and  Services 

Maintenance  Test  Data  and  Services  (MTDs)  provide  a  standard  representation  of  maintenance  data  in 
the  test  environment.  MTD  enhances  runtime  execution  of  the  test  program  by  capturing  and  using 
information  developed  during  maintenance  activities.  This  directly  interfaces  with  the  Diagnostic 
Processing  Interface  Protocol  interface  by  providing  information  that  can  supplement  diagnostic 
capabilities. 

CS.ATS.6.2(a)  Emerging.  The  following  standards  are  emerging: 

-  IEEE  PI 522,  IEEE  Testability  Standard. 

-  IEEE  1545-1999,  Trial  Use  Standard  for  Parametric  Data  Logging  and  Format. 

CS.ATS.6.3  Product  Design  Data 

Product  Design  Data  (PDD)  originates  in  the  design  process  and  is  needed  for  the  development  and 
sustainment  of  test  and  diagnostics.  PDD  includes  information  about  structures  that  are  present  in  the 
product  solely  or  principally  to  support  test  and  diagnostics  and  facilitates  the  transfer  of  information 
from  CAD  workstations  to  the  TPS  development,  reducing  errors  and  development  time.  PDD  supports 
the  back-annotation  of  test  and  maintenance  information  into  the  design  environment,  reducing 
sustainment  costs. 

CS.ATS.6.3(a)  Emerging.  The  following  standard  is  emerging: 

-  ANSI/EIA  682-1996:  EDIF  Electronic  Design  Interchange  Format,  Version  400,  Reference 
Manual  and  Information  Model. 

CS.ATS.6.4  Built-In  Test  Data 

Built-in  Test  Data  (BTD)  provides  a  standard  representation  of  Built-in  Test  (BIT)  data  into  the  test 
environment.  BTD  will  improve  runtime  execution  of  test  programs  by  providing  guidance  to  the 
diagnostic  services  within  an  ATS.  During  TPS  development,  candidate  BIT  requirements  can  be 
evaluated  by  contrasting  the  impact  on  design  and  production  against  maintenance  and  diagnostic  test. 
Cost-effective  BIT  requirements  can  then  be  imposed  as  design  constraints.  New  initiatives  in  the  area 
of  BIT  architecture  and  information  exchange  mechanisms  are  also  being  evaluated. 

CS.ATS.6.4(a)  Emerging.  The  following  standards  are  emerging: 

-  IEEE  1149.1-2001 ,  IEEE  Standard  Test  Access  Port  and  Boundary-Scan  Architecture. 

-  IEEE  1149.4-1999,  Mixed-Signal  Test  Bus. 
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-  IEEE  1149.5-1995,  IEEE  Standard  for  Module  Test  and  Maintenance  Bus  (MTM-Bus) 
Protocol. 

-  IEEE  1545-1999,  Standard  for  Parametric  Data  Log  Format,  1 999. 

CS.ATS.7  Subdomain-Specific  Service  Areas 

This  section  addresses  Subdomain-Specific  Service  Areas  required  by  the  ATS  in  addition  to  the 
standards  cited  in  the  JTA  Core  and  Combat  Support  Domain. 

CS.ATS.7.1  Platform/Environment  Services 

This  section  identifies  platform/environment  services  required  by  the  ATS  in  addition  to  the  standards 
cited  in  the  JTA  Core  and  Combat  Support  Domain. 

CS.ATS.7.1. 1  System  Framework  Standards 

System  frameworks  provide  a  common  interface  for  developers  of  software  modules,  ensuring  that  they 
are  portable  to  other  computers  that  conform  to  the  specified  framework.  By  defining  system 
frameworks,  suppliers  can  focus  on  developing  programming  tools  and  instrument  drivers  that  can  be 
used  with  any  ADE  that  is  compliant  with  the  framework.  System  frameworks  contain,  but  are  not 
limited  to,  the  following  components: 

□  Compatible  ADEs. 

□  Instrument  Drivers. 

□  Operating  System. 

□  Required  Documentation  and  Installation  Support. 

□  Requirements  for  the  Control  Computer  Hardware. 

□  Soft  Front  Panel. 

□  VISA  Interface  and  I/O  Software. 

□  VXI  Instruments,  VXI  slotO,  System  Controller,  VXI  Mainframe. 

A  system  designed  using  a  VXI-plug  &  play  system  framework  ensures  that  the  ADE,  DRV,  GIC,  ICM, 
and  other  FRM  components  are  compatible  and  interoperable  with  each  other.  Following  the  system 
framework  requirements  also  ensures  that  all  necessary  system  components  have  been  included, 
resulting  in  a  complete  and  operational  system.  System  frameworks  increase  the  likelihood  that  ADEs 
will  be  available  on  multiple  platforms,  greatly  enhancing  the  ability  to  move  test  software  between 
platforms.  While  this  does  not  ensure  total  portability  of  TPSs,  it  does  eliminate  the  need  to  translate  or 
rewrite  the  source  code  when  it  is  ported. 

CS.ATS.7.1. 1(a)  Emerging.  The  following  standard  is  emerging: 

-  VPP-2,  VXI  plug  &  play  (VPP)  Systems  Alliance  System  Frameworks  Specification, 

Revision  4.2,  17  March  2000. 

CS.ATS.7.1 .2  Receiver/Fixture  Interface 

The  Receiver/Fixture  (RFX)  and  generic  pin  map  interfaces  represent  a  central  element  of  the  ATS 
through  which  the  majority  of  stimulus  and  measurement  reach  the  UUT.  Standardization  of  the  RFX 
and  pin  map  allows  the  same  fixture  to  be  used  on  multiple  ATSs.  A  standard  pin  map  restricts  the  types 
of  signals  present  at  different  positions  on  the  receiver.  Standardization  of  this  interface  increases  the 
interoperability  of  test  program  sets,  resulting  in  lower  re-host  costs. 
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CS.ATS.7.1.2(a)  Emerging.  The  following  standard  is  emerging: 

-  IEEE  PI 505,  Receiver  Fixture  Interface  (RFI)  Standard,  Volume  RFI-3,  Revision  4.0, 

16  July  2001. 

CS.ATS.7.1.3  Switching  Matrix  Interface 

The  Switching  Matrix  (SWM)  interface  and  ATS  receiver/fixture  pin  map  represent  a  central  element 
of  the  ATS  for  connecting  ATS  instrumentation  to  the  UUT  through  a  switch  matrix.  The  SWM  allows 
a  variety  of  instruments  to  be  connected  to  multifunction  terminals  identified  by  a  standard 
receiver/fixture  pin  map.  The  combination  of  standardizing  the  SWM  interface  and  a  common 
receiver/fixture  pin  map  gives  the  ATS  the  capability  to  accommodate  any  fixture  that  conforms  to  the 
pin  map.  Standardization  of  the  SWM  interface  and  receiver/fixture  pin  map  increases  interoperability 
by  ensuring  that  ATS  instruments  needed  to  test  a  UUT  can  be  switched  to  pins  required  by  the  fixture. 

CS.ATS.7.1.3(a)  Emerging.  The  following  standard  is  emerging: 

-  IEEE  PI 552-1 999,  Standard  Architecture  for  Test  Systems  (SATS). 

CS.ATS.7.1.4  Other  Interfaces 

The  interfaces  described  in  this  section  are  provided  for  completeness  of  the  ATS  Subdomain  and  to 
make  readers  aware  that  these  interfaces  have  been  addressed.  Standards  for  these  interfaces  are  not 
mandated,  because  they  were  not  found  to  be  key  for  the  generic  open  system  architecture  for  ATS. 

CS.ATS.7.1.4.1  Computer  Asset  Controller  Interface 

The  Computer  Asset  Controller  (CAC)  interface  describes  the  communication  paths  between  the  host 
computer  and  instrument  controllers  in  a  distributed  system.  These  interfaces  may  be  internal  or 
external  to  the  host  computer.  Examples  of  internal  interfaces  are  Industry  Standard  Architecture  (ISA) 
and  Peripheral  Component  Interface  (PCI).  Examples  of  external  interfaces  are  IEEE-488,  RS-232, 
Ethernet,  Multisystem  Extension  Interface,  and  Modular  System  Interface  Bus. 

CS.ATS.7.1.4.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.ATS.7.1.4.2  Host  Computer  Interface 

Host  Computer  Interface.  The  Host  Computer  (HST)  interface  describes  the  processing  architecture  of 
the  primary  control  computer  in  which  the  TPS  is  executed  and  through  which  the  operator  interfaces. 
Portions  of  the  HST  interface  affect  the  interoperability  of  ATS.  These  requirements  are  included  in  the 
Frameworks  software  interface. 

CS.ATS.7.1. 4.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.ATS.7.1.4.3  Instrument  Control  Bus  Interface 

The  Instrument  Control  Bus  (ICB)  interface  describes  the  connection  between  the  host  computer  or 
instrument  controller  and  the  test  and  measurement  instruments  in  the  ATS.  Examples  of  these 
interfaces  are  IEEE-488,  VME,  and  VME  Extensions  for  Instrumentation  (VXI). 

CS.ATS.7.1. 4.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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CS.ATS.7.1.4.4  Instrument  Command  Language 

Instrument  Command  Language.  The  Instrument  Command  Language  (ICL)  interface  describes  how 
instrument  commands  and  results  are  expressed  as  they  enter  or  leave  test  and  measurement 
instruments.  The  requirements  for  this  interface  arc  satisfied  by  the  DRV  and  GIC  interfaces. 

CS.ATS.7.1. 4.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.ATS.7.2  Application  Development  Environments 

The  Application  Development  Environments  (ADE)  interface  describes  how  the  test  engineer  creates 
and  maintains  a  TPS,  whether  it  is  captured  in  the  form  of  a  text  or  graphical  language.  This  interface 
was  not  mandated,  because  the  requirements  for  the  ADE  arc  restricted  by  the  FRM  interface. 

CS.ATS.7.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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CS.DTS:  Defense  Transportation  System  Subdomain 

CS.DTS.1  Subdomain  Description 

The  Defense  Transportation  System  (DTS)  is  an  integrated  cargo-  and  personnel-delivery  system 
providing  worldwide  transportation  functions  for  the  Department  of  Defense  (DoD).  It  consists  of 
35  core  information  systems  with  interfaces  to  countless  DoD,  Federal,  state  government,  and 
law-enforcement  agencies  nationwide.  Information  concerning  the  35  DTS  systems  can  be  found  in  the 
Defense  Transportation  System  Enterprise  Architecture,  Version  2.0,  11  January  2001,  at: 
https://business.transcom.mil/J6/j6a/archl.html  (accessible  from  .mil  domains  only). 

CS.DTS.2  Purpose  and  Scope 

The  Defense  Transportation  System  Subdomain  for  the  Combat  Support  Domain  identifies  additions  to 
standards,  interfaces,  and  service  areas  contained  in  the  Department  of  Defense  (DoD)  Joint  Technical 
Architecture  (JTA)  Core  and  Combat  Support  Domain  that  pertain  to  the  DTS.  Also  included  are 
additional  standards  central  to  the  interoperability  of  existing  DTS  information  systems.  The  standards 
specified  in  the  JTA  Core,  the  Combat  Support  Domain,  and  the  Modeling  and  Simulation  Domain, 
combined  with  those  in  this  document,  comprise  the  minimum  set  of  standards  for  the  DTS.  Military 
standards  are  mandated  only  when  suitable  commercial  standards  are  not  available,  are  not  mature,  or 
do  not  meet  the  requirements. 

The  Transportation  System  Subdomain  includes  the  information  systems,  information,  personnel,  and 
facilities  engaged  in  providing  transportation  support  functions  within  DoD.  These  consist  of 
component  systems  that  support  discrete  functional  areas  within  the  DTS  Subdomain,  such  as: 

□  Modeling  and  Simulation 

□  Financial  billing,  payment,  and  tracking 

□  Transport  of  cargo  and  personnel 

CS.DTS.3  Applicability 

This  subdomain  applies  to  all  new  and  existing  information  systems  that  make  up  the  Defense 
Transportation  System  including  upgrades  to  existing  systems. 

CS.DTS.4  Background 

The  DTS  was  selected  for  inclusion  in  the  CS  Domain  based  on  critical  requirements  for  current, 
reliable,  and  accessible  visibility  of  in-transit,  scheduled,  and  actual  cargo  and  personnel  movements, 
through  which  warfighter  resources  and  operations  may  be  based.  Visibility  can  only  be  achieved  if 
information  from  a  variety  of  DoD  and  non-DoD  sources  is  available.  The  DTS  must  be  able  to  readily 
exchange  information  with  commercial  suppliers  as  well  as  traditional  DoD  communities  of  interest. 

CS.DTS.5  Core-Related  Information  Technology  Categories 

This  section  identifies  additional  standards  (mandatory  and  emerging)  unique  to  the  DTS  Subdomain 
of  the  Combat  Support  Domain. 

CS.DTS.5. 1  Product  Data  Interchange 

To  promote  interoperability  among  military  activities  and  commercial  vendors,  DoD  has  adopted 
standards  endorsed  by  the  commercial  industry  in  lieu  of  developing  unique  military  standards.  The 
current  DoD  standards  include  those  adopted  for  the  linear  bar  code  (Code  39  approved 
November  1982)  and  2D  bar  code  (PDF-417,  approved  July  1995).  Bar  code  standards  arc  used  to 
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easily  identify  packages  and  products.  Linear  bar  codes  such  as  AIM  BC-1  have  limited  data  storage 
capability,  typically  a  maximum  17  characters.  A  two-dimensional  (2D)  material-handling  standard 
was  developed  to  allow  for  greater  storage,  up  to  1,850  characters.  2D  bar  codes  can  also  sustain 
considerable  damage  and  still  be  read.  To  effectively  use  PDF-417  requires  a  method  of  identifying  and 
parsing  the  multiple  data  elements  that  can  now  be  encoded  in  a  single  media.  Use  of  standard  data 
syntax  and  standard  data  semantics  facilitates  the  accurate  and  efficient  interpretation  of  these  multiple 
data  elements.  ISO  15418  lists  the  approved  data  identifiers  and  their  definitions.  ISO  15434  describes 
the  message  structure  and  format  for  encoding  data  into  high  capacity  automatic  data  capture  (ADC) 
media.  PDF-417  answers  the  need  to  capture,  store,  and  transfer  large  amounts  of  data  inexpensively.  It 
can  exchange  complete  data  files  (such  as  text,  numerics,  or  binary)  and  encode  graphics,  fingerprints, 
shipping  manifests,  electronic  data  interchange  (EDI)  messages,  equipment  calibration  instructions, 
and  much  more.  It  provides  a  powerful  communications  capability  without  the  need  to  access  an 
external  database. 

CS.DTS.5.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.DTS.5.2  Information  Security  Standards 

This  section  identifies  information  security  standards  required  by  the  DTS  in  addition  to  the  standards 
cited  in  the  JTA  Core  and  Combat  Support  Domain. 

CS.DTS.5.2(a)  Emerging.  Secure  Shell  is  a  protocol  used  to  log  into  another  computer  over  a  network, 
to  execute  commands  in  a  remote  machine,  and  to  move  files  from  one  machine  to  another.  It  provides 
strong  authentication  and  secure  communications  over  insecure  channels.  The  following  Secure  Shell 
standards  are  emerging: 

-  draft-IETF-secsh-transport-15.txt,  SSH  Transport  Layer  Protocol,  20  September  2002. 

-  draft-IETF-secsh-iiserauth-16.txt,  SSH  Authentication  Protocol,  20  September  2002. 

-  draft-IETF-secsh-connect-16.txt,  SSH  Connection  Protocol,  20  September  2002. 
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CS.HR:  Human  Resources  Subdomain 

CS.HR.1  Subdomain  Description 

Military  personnel  and  pay  functions  support  Active  duty.  Guard,  and  Reserve  personnel  (and  their 
families)  throughout  their  entire  military  careers — through  periods  of  peacetime,  mobilization  and 
war — and  beyond  their  military  service.  These  functions  comprise  the  military  personnel  mission  area 
as  described  in  the  Defense  Information  Infrastructure  Version  3.1  and  support  the  management, 
planning,  administration,  training,  and  programming  of  resources  for  military  manpower  functions  as 
prescribed  by  Federal  law  as  well  as  Department  of  Defense  (DoD)  and  Service  directives  and 
regulations.  Many  of  the  core  military  personnel  and  pay  functions  arc  performed  in  the  field  and  are 
directly  related  to  readiness,  force  management,  and  strength  accounting.  OMB  Policy  Letter  92-1 
defines  an  inherently  governmental  function  as  one  involving  an  exercise  of  the  Government’s 
discretionary  authority  in  choosing  among  courses  of  action.  Virtually  all  of  the  underlying  military 
personnel  management  functional  activities  meet  this  definition  (e.g.,  decisions  on  accessions,  rating, 
rewarding,  promoting,  mobilizing,  assigning,  retaining,  and  separating). 

DoD  Human  Resources  systems  will  evolve  and/or  be  replaced  to  provide  for  this  functionality.  In  their 
place  will  be  a  single,  fully  integrated  military  personnel  and  pay  management  system  for  all  of  the 
Department  of  Defense  (DoD)  military  Services  and  Components.  It  will  significantly  improve  support 
to  Joint  Commanders  by  providing  the  capability  to  track  personnel  regardless  of  Service/Component 
in  any  location  or  environment.  Additionally,  it  will  provide  the  military  Service  headquarters  with  an 
enhanced  capability  to  manage  the  force,  as  well  as  providing  individual  Service  members  with 
simplified,  easily  available  personnel  and  pay  management  support.  The  single  system  will  implement 
reengineered  DoD  field,  headquarters,  and  corporate  business  processes  based  on  best  practices  for  core 
human  resource  and  pay  functions  used  by  the  military  community  and  the  commercial  sector.  In 
achieving  full  integration  of  personnel  and  pay  management  functions,  the  single  system  will  provide 
the  following: 

□  The  means  for  Joint  Commanders  to  access  for  timely,  accurate,  and  consistent  information  on 
personnel  assets 

□  One-time  entry  of  data  that  automatically  triggers  all  associated  personnel  and  pay 
management  transactions 

□  Simplified,  easily  available,  accurate  personnel  and  pay  management  support  for  Active, 
Reserve/Guard,  and  Retired  Service  members 

□  A  mechanism  for  the  Services  to  quickly  and  selectively  activate,  mobilize,  and  deploy 
personnel  assets,  while  maintaining  an  accurate  accounting  of  the  status  and  location  of  those 
assets 

CS.HR.2  Purpose  and  Scope 

The  Human  Resources  Subdomain  for  the  Combat  Support  Domain  identifies  additions  to  standards, 
interfaces,  and  service  areas  contained  in  the  DoD  Joint  Technical  Architecture  (JTA)  Core  and  Combat 
Support  Domain  that  pertain  to  Human  Resources  systems  and  external  systems  that  must  interoperate 
with  them. 

The  standards  specified  in  the  JTA  Core  and  the  Combat  Support  Domain,  combined  with  those  in  this 
document,  comprise  the  minimum  set  of  standards  for  use  by  DoD  Human  Resource  systems. 
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Military  standards  are  mandated  only  when  suitable  commercial  standards  are  not  available,  are  not 
mature,  or  do  not  meet  the  requirements. 

CS.HR.3  Applicability 

This  subdomain  applies  to  all  new  and  existing  information  systems  being  upgraded  that  address 
Human  Resource  needs  of  DoD. 

CS.HR.4  Background 

Standards  beyond  those  in  the  JTA  Core  and  the  Combat  Support  Domain  are  necessary  to  be  specified 
in  this  subdomain  to  minimize  interoperability  risks  as  new  HR  systems  come  online  and  as  existing 
ones  get  upgraded.  JTA  Core  and  Combat  Support  Domain  standards  facilitate  minimizing 
interoperability  risks  to  a  degree.  Standards  specified  in  this  document  further  minimize  those  risks  by 
clarifying  information  exchange  XML  tags  and  semantics,  with  and  between  human  resource  systems. 

CS.HR.5  Core-Related  Information  Technology  Categories 

Standards  in  the  Information  Processing  -  Data  Interchange  Standards  area  are  specified  below. 
Additional  standards  in  this  and  other  standards  areas  may  soon  be  specified,  providing  further 
elaboration  of  hierarchically  superior  standards. 

CS.HR.5. 1  Information  Processing 

This  section  identifies  information  processing  standards  required  by  the  human  resources  community 
in  addition  to  the  standards  cited  in  the  JTA  Core  and  Combat  Support  Domain. 

CS.HR.5. 1.1  Document  Interchange 

This  section  identifies  document  interchange  standards  required  by  the  human  resources  community  in 
addition  to  the  standards  cited  in  the  JTA  Core  and  Combat  Support  Domain. 

CS.HR.5. 1.1  (a)  Emerging.  The  following  standard  describes  the  form  of  the  Person  Name  object  used 
in  HR-XML  specifications  and  is  emerging: 

-  HR-XML.  Consortium  Standard  for  Person  Name,  Version:  1 .0,  (8  November  2000). 

Staffing  Exchange  Protocol  (SEP)  is  simple  protocol  for  communication  of  information  about  job  or 
position  opportunities  to  job  boards  and  other  Internet  recruiting  venues.  The  protocol  also  provides  the 
return  of  information  about  job/position  seekers.  The  following  standard  is  emerging: 

-  HR-XML  Consortium  Standard  for  Staffing  Exchange  Protocol  (SEP),  Version:  1.0, 

(8  November  2000). 
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CS.MED:  Medical  Subdomain 

CS.MED.1  Subdomain  Description 

The  Medical  (MED)  Subdomain  includes  the  information  systems,  information,  personnel,  and 
facilities  engaged  in  providing  healthcare  and  medical  support  functions  within  the  Department  of 
Defense  (DoD).  These  consist  of  component  systems  that  support  the  following  information 
management  core  business  processes  within  the  Medical  Subdomain: 

□  Access  to  Care:  the  front-end  process  that  starts  with  the  identification  of  a  care  need(s)  by  the 
beneficiary  or  provider  and  stops  prior  to  the  care  being  delivered. 

□  Provision  of  Health  Services:  beneficiary-  and  command-focused  proactive,  continual  process 
of  achieving  the  best  possible  health  status  for  individuals  and  populations  through  screening, 
assessment  and  intervention. 

□  Population  Health  Management:  process  for  optimizing  the  health,  health  planning,  and  health 
management  of  all  beneficiaries. 

□  Manage  the  Business:  administrative  infrastructure  support  and  physical  infrastructure  support 
processes  that  include  financial  services,  operational  support,  human  resources,  managed  care 
contracting,  billing,  materials  management  and  other  administrative  services. 

These  information  systems  provide  the  ability  to  capture,  store,  transmit,  and  process  medical 
information  at  military  treatment  facilities  and  other  sites  around  the  world.  In  addition,  they  interface 
with  commercial  medical  service  providers. 

CS.MED.2  Purpose  and  Scope 

The  Medical  Subdomain  identifies  additions  to  the  standards,  interfaces,  and  service  areas  contained  in 
the  DoD  Joint  Technical  Architecture  (JTA)  Core  and  Combat  Support  Domain  that  pertain  to  medical 
systems.  These  additions  arc  common  to  the  majority  of  systems  in  the  Medical  Subdomain  and  support 
the  interoperability  requirements  of  those  systems. 

The  standards  specified  in  the  JTA  Core  and  the  Combat  Support  Domain,  combined  with  those  in  this 
subdomain,  comprise  the  minimum  set  of  standards  for  the  Military  Health  System  (MHS). 

CS.MED.3  Applicability 

This  subdomain  applies  to  all  new  and  upgraded  medical  information  systems. 

CS.MED.4  Background 

The  MHS  is  an  integrated  healthcare  delivery  system  that  provides  health  care  to  its  beneficiary 
population  largely  consisting  of  active-duty  personnel,  their  dependents,  and  retirees.  It  is  a  global 
enterprise  composed  of  over  600  military  treatment  facilities  located  around  the  world.  The  dynamic 
nature  of  the  MHS,  together  with  the  mobility  of  the  beneficiary  community,  makes  it  important  to 
ensure  that  the  right  information  is  in  the  right  place  at  the  right  time.  Furthermore,  the  MHS  requires 
the  ability  to  exchange  this  information  within  DoD,  and  with  other  Federal  agencies  and  industry. 

The  healthcare  enterprise  is  a  unique  and  rapidly  evolving  industry.  Because  of  this  changing 
environment,  it  becomes  even  more  critical  that  the  MHS  maintain  the  ability  to  readily  exchange 
information  both  within  and  outside  DoD.  Within  this  Medical  Subdomain  arc  established  and 
emerging  standards  that  will  be  building  blocks  used  in  the  design,  development,  and  integration  of 
information  systems.  Standardization  is  a  key  enabler  within  the  strategic  direction  of  the  MHS 
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information  management  program  to  provide  support  for  the  business  needs  of  the  military  healthcare 
enterprise. 

CS.MED. 5  Core-Related  Information  Technology  Categories 

The  following  medical-specific  standards  concerning  medical  Electronic  Data  Interchange  (EDI), 
medical  still  imagery  data  interchange,  medical  information  exchange,  and  information  security  have 
been  identified  by  the  Medical  Subdomain  in  addition  to  the  standards  found  in  the  JTA  Core  and  the 
Combat  Support  Domain. 

CS.MED. 5.1  Medical  Electronic  Data  Interchange 

The  following  EDI  standards  are  used  for  clinical,  healthcare  administrative,  and  retail  pharmacy 
transactions.  This  section  includes  the  standards  required  by  the  final  rules  for  implementing  the  Health 
Insurance  Portability  and  Accountability  Act  (HIPAA). 

CS.MED. 5.1 .1  Clinical  Transactions 

Health  Level  Seven  (HL7)  is  a  standard  for  EDI  in  healthcare  environments.  It  standardizes  the  format 
and  protocol  for  the  exchange  of  formatted  messages  containing  medical  data  among  medical  software 
applications.  It  is  to  be  used  for  the  interchange  of  medical  data,  specifically  patient  records  and 
clinical,  epidemiological,  and  regulatory  data.  The  use  of  the  HL7  standards  under  these  specified 
conditions  is  in  accordance  with  Federal  Information  Processing  Standards  Publication 
(FIPS  PUB)  161-2,  EDE  HL7  standards  should  not  be  used  for  healthcare  insurance  administrative 
applications  (such  as  for  enrollments,  claims,  and  claim  payments)  or  the  Government  procurement 
cycle  (such  as  registration  of  vendors,  requests  for  quotes,  purchase  order,  shipping  notice,  or  payment 
advice). 

CS.MED.5.1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.MED.5.1.2  Healthcare  Administrative  Transactions 

As  published  in  the  Federal  Register/Vol.  65,  No.  160/Thursday,  August  17,  2000/Rules  and 
Regulations,  final  rules  implementing  HIPAA  require  the  use  of  revised  versions  of  implementation 
specifications  for  specific  health  insurance  EDI  transactions  developed  by  the  American  National 
Standards  Institute  (ANSI)  Accredited  Standards  Committee  (ASC)  X12  Insurance  Subcommittee 
(X12N).  Current  information  on  the  required  compliance  date  can  be  found  on  the  Department  of 
Health  and  Human  Services’  Administrative  Simplification  Web  site  at: 
http://aspe.hhs.gov/admnsimp/index.htm. 

CS.MED.5. 1.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.MED.5.1.3  Retail  Pharmacy  Transactions 

The  National  Council  for  Prescription  Drug  Programs  (NCPDP)  has  published  standards  for  retail 
pharmacy  claims  EDI.  These  standards  apply  to  the  transmission  of  prescription  drug  and 
pharmaceutical  care  benefit/distribution  and  delivery  information  including  online,  real-time  drug 
utilization  review,  and  financial  claims  data  between  pharmacies  and  trading  partners. 

As  published  in  the  Federal  Register/Vol.  65,  No.  160/Thursday,  August  17,  2000/Rules  and 
Regulations,  final  rules  implementing  HIPAA  require  the  use  of  NCPDP  standards  for  the  transmission 
of  health  plan  transactions  concerning  prescription  drugs  and  pharmaceuticals.  Current  information  on 
the  required  compliance  date  can  be  found  on  the  Department  of  Health  and  Human  Services' 
Administrative  Simplification  Web  site  at:  http ://aspe.hhs . go v/admnsimp/index. htm. 
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CS.MED.5. 1.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.MED.5.2  Medical  Still  Imagery  Data  Interchange 

The  Digital  Imaging  and  Communications  in  Medicine  (DICOM)  standard  describes  a  means  for 
formatting  and  exchanging  images  and  associated  information.  It  applies  to  the  operation  of  the 
interface  used  to  exchange  data  among  medical  imaging  devices. 

The  DICOM  standard  was  developed  jointly  by  the  medical  user  community,  represented  by  the 
American  College  of  Radiology  (ACR),  and  medical  equipment  manufacturers,  represented  by  the 
National  Electrical  Manufacturers  Association  (NEMA).  It  has  since  been  adopted  by  the  European 
Committee  for  Standardization  (CEN)  Technical  Committee  (TC)  251  and  the  Japanese  Industry 
Association  for  Radiation  Apparatus  (JIRA). 

Additional  information  can  be  found  on  the  DICOM  Web  page  at: 
http://medical.nema.org/DICOM.html. 

CS.MED.5.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

CS.MED. 5.3  Medical  Information  Exchange  Standards 

There  are  many  widely  accepted  standards  for  the  format  and  content  of  medical  information  to  be 
exchanged  among  medical-application  software  entities.  In  particular,  the  International  Society  for 
Blood  Transfusion  (ISBT)  has  developed  a  standard,  ISBT  128,  for  bar-coding  blood  donor  label 
information  on  blood  bags.  Also,  the  Universal  Product  Number  (UPN)  System,  published  by  the 
Health  Industry  Business  Communications  Council,  is  a  standard  for  identifying  medical  and  surgical 
products  in  the  supply  chain.  Reference  the  following  Health  Industry  Business  Communications 
Council  Web  site  for  more  information:  http://www.hibcc.org/upndb.htm. 

CS.MED.5.3(a)  Emerging.  The  following  standard  is  emerging: 

-  ISBT  128,  Bar  Code  Symbology  and  Application  Specification  for  Labeling  of  Whole  Blood  and 
Blood  Components,  Version  1.4.0,  June  2001. 

CS.MED.5.4  Information  Security  Standards 

This  section  identifies  information  security  standards  required  to  ensure  secure  interoperability  of 
medical  data  that  is  processed,  stored  and  transmitted  on  MHS  Automated  Information  Systems  (AISs) 
and  Networks. 

The  Military  Health  Services  System  (MHSS)  Automated  Information  System  (AIS)  Security  Policy 
Manual,  Version  1.0,  April  1996,  published  by  the  Office  of  the  Assistant  Secretary  of  Defense  (Health 
Affairs)  contains  information  security  policies,  procedures,  and  guidance  for  the  Military  Health 
System  (MHS)  AISs  and  Networks  that  process,  store  and  transmit  medical  and  patient  data.  This 
manual  is  currently  under  revision. 

CS.MED.5.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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M&S:  Modeling  and  Simulation  Domain 

M&S.1  Domain  Description 

This  domain  provides  a  set  of  standards  affecting  the  definition,  design,  development,  execution,  and 
testing  of  models  and  simulations.  Department  of  Defense  (DoD)  modeling  and  simulation  ranges  from 
high-fidelity  engineering  simulations  to  highly  aggregated,  campaign-level  simulations  involving  joint 
forces.  Increasingly,  DoD  and  supporting  industries  are  integrating  and  operating  a  mix  of  computer 
simulations,  actual  warfighting  systems,  weapon  simulators,  and  instrumented  ranges  to  support  a 
diversity  of  applications  including  training,  mission  rehearsal,  operational  course  of  action  analysis, 
investment  analysis,  and  many  aspects  of  acquisition  support  throughout  all  phases  of  the  system  life 
cycle. 

M&S.2  Purpose 

The  Modeling  and  Simulation  (M&S)  Domain  identifies  additions  to  the  JTA  Core  elements  (standards, 
interfaces,  and  service  areas)  listed  in  the  JTA  Core.  These  additional  standards  are  key  to  the 
Interoperability  of  M&S  within  DoD  among  themselves  and  real-world  systems. 

M&S.3  Scope  and  Applicability 

In  November  2000,  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology  (USD[A&TJ) 
approved  a  Memorandum  of  Agreement  (MoA)  between  members  of  the  DoD  Executive  Council  for 
Modeling  and  Simulation  (EXCIMS).  The  MoA  reaffirms  the  adopting  of  the  High  Level  Architecture 
(HLA)  as  the  standard  technical  architecture  for  DoD  simulation  interoperability.  The  HLA  is  a 
technical  architecture  that  applies  to  all  classes  of  simulations,  including  virtual  simulations, 
constructive  simulations,  and  interfaces  to  live  systems.  The  virtual  simulation  class  comprises 
human-in-the-loop  simulators.  The  constructive  simulation  class  includes  wargames  and  other 
automated  simulations  that  represent  actions  of  people  and  systems  in  the  simulation.  The  live 
simulation  class  includes  C4I  interfaces,  weapon  systems/platforms  with  embedded  collective  training, 
and  instrumented  ranges.  For  compliance  guidance,  see  MoA  at:  http://www.dmso.mil  (Home: 
Warfighter:  HLA:  Helpful  Resources). 

M&S  developed  as  an  integral  part  of  a  weapon  system  or  C4I  system,  or  as  an  embedded  simulation, 
will  fall  under  the  mandates  of  the  JTA  main  body,  this  domain,  and  any  other  applicable  domains. 
Interoperability  of  embedded  simulations  will  be  governed  by  this  domain.  The  HLA  and  related  M&S 
standards  listed  here  address  those  key  technical  aspects  of  simulation  design  necessary  to  foster 
interoperability  and  reuse,  but  avoid  overly  constraining  implementation  details.  They  are  intended  for 
use  in  simulations  addressing  a  full  range  of  training,  analysis,  and  acquisition  requirements,  each  of 
which  may  have  different  objectives  that  dictate  different  representational  details,  timing  constraints, 
processing  demands,  etc.  The  M&S  technical  standards  in  this  domain  provide  the  framework  within 
which  specific  systems,  targeted  against  precise  requirements,  can  be  developed.  While  many  of  these 
systems  will  operate  in  computational  environments  considered  standard  and  that  fall  within  the 
spectrum  of  the  other  JTA  standards,  some  may  require  massively  parallel  processing  or  other  unique 
laboratory  configurations,  bringing  with  them  their  own  set  of  requirements.  Simulation  developers 
should  follow  those  standards  required  for  the  environment  in  which  the  simulation  is  implemented. 
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M&S.4  Background 

In  1992,  DoD  established  a  vision  for  modeling  and  simulation,  as  stated  in  the  DoD  M&S  Master  Plan. 
Defense  modeling  and  simulation  will  provide  readily  available,  operationally  valid  environments  for 
use  by  the  DoD  Components 

□  To  train  jointly,  develop  doctrine  and  tactics,  formulate  operational  plans,  and  assess 
warfighting  situations. 

□  To  support  technology  assessment,  system  upgrade,  prototype  and  full-scale  development,  and 
force  structuring. 

Common  use  of  these  environments  will  promote  a  closer  interaction  between  the  operations  and 
acquisition  communities  in  carrying  out  their  respective  responsibilities.  To  allow  maximum  utility  and 
flexibility,  these  modeling  and  simulation  environments  will  be  constructed  from  affordable,  reusable 
components  interoperating  through  an  open  systems  architecture  (Executive  Council  for  Modeling  & 
Simulation). 

Department  of  Defense  Directive  5000.59,  DoD  Modeling  and  Simulation  (M&S)  Management, 
January  4,  1994;  and  DoD  5000.59-P,  DoD  Modeling  and  Simulation  (M&S)  Master  Plan  (MSMP), 
October  1995,  outline  DoD  policies,  organizational  responsibilities,  and  management  procedures  for 
M&S  and  provide  a  comprehensive  strategic  plan  to  achieve  DoD’s  vision  of  readily  available, 
authoritative,  interoperable,  and  reusable  simulations. 

Objective  1  of  the  DoD  MSMP  states  “Provide  a  common  technical  framework  for  M&S”  and  includes, 
under  sub-objective  1- 1 ,  the  establishment  of  “a  common  high-level  simulation  architecture  to  facilitate 
the  interoperability  of  all  types  of  simulations  among  themselves  and  with  C4I  systems,  as  well  as  to 
facilitate  the  reuse  of  M&S  components.”  The  efficient  and  effective  use  of  models  and  simulations 
across  DoD  and  supporting  industries  requires  a  common  technical  framework  for  M&S  to  facilitate 
interoperability  and  reuse.  This  common  technical  framework  consists  of: 

□  A  high-level  architecture  (HLA)  to  which  simulations  must  conform. 

□  Conceptual  models  of  the  mission  space  (CMMS)  to  provide  a  basis  for  the  development  of 
consistent  and  authoritative  M&S  representation. 

□  Data  standards  to  support  common  understanding  of  data  across  models,  simulations,  and 
real-world  systems. 

The  HLA  is  a  progression  from  the  previous  architectures  and  associated  standards  that  have  been 
developed  and  used  successfully  for  specific  classes  of  simulation.  These  include  Distributed 
Interactive  Simulation  (DIS)  protocol  standards,  which  support  networked,  real-time,  platform-level 
virtual  simulation;  and  the  Aggregate-Level  Simulation  Protocol  (ALSP),  which  is  used  to  support 
distributed,  logical-time,  constructive  simulations.  The  HLA  provides  a  common  architecture  for  all 
classes  of  simulation  and,  consequently,  the  HLA  supersedes  both  the  DIS  and  ALSP  standards. 
Transition  of  simulations  from  use  of  other  standards  is  underway  in  accordance  with  DoD  M&S 
policy. 

M&S.5  Core-Related  Information  Technology  Categories 

The  following  standards  apply  in  addition  to  those  found  in  the  JTA  Core.  The  HLA  Rules,  the  HLA 
Interface  Specification  and  the  HLA  Object  Model  Template  Specification  define  the  HLA. 
Compliance  criteria  have  been  set  forth  in  the  compliance  checklist,  which  was  developed  as  part  of  the 
HLA,  along  with  the  HLA  test  procedures.  These  form  the  technical  basis  for  HLA  compliance.  Current 
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versions  are  listed  and  available  at  the  defense  Modeling  and  Simulation  Office  Web  site  at: 
http://www.dmso.mil. 

M&S.5.1  Information  Processing  Standards 

In  addition  to  those  mandates  for  information  processing  standards  described  in  Section  2  of  the  JTA 
Core,  the  following  are  unique  mandates  applicable  to  the  Modeling  and  Simulation  Domain. 

M&S.5.1(a)  Emerging.  The  Standards  Board  of  the  Institute  of  Electrical  and  Electronics  Engineers 
(IEEE)  voted  on  September  21,  2000,  to  accept  the  HLA  as  an  IEEE  standard.  As  a  result  of  that 
decision,  Defense  Modeling  and  Simulation  Office  (DMSO)  is  building  a  Runtime  Infrastructure  (RTI) 
to  the  new  HLA  1516.1  specification.  Prior  to  use  by  the  DoD  it  must  be  verified.  In  addition,  DMSO 
produced  tools  will  also  be  migrated  to  the  1516  specification.  Therefore,  the  following  standards  are 
emerging: 

-  IEEE  1516-2000,  IEEE  Standard  for  Modeling  and  Simulation  (M&S)  High  Level  Architecture 
(HLA)  -  Framework  and  Rules,  2000. 

-  IEEE  1516.1-2000,  IEEE  Standard  for  Modeling  and  Simulation  (M&S)  High  Level  Architecture 
(HLA)  -  Federate  Interface  Specification,  2000. 

-  IEEE  1516.2-2000,  IEEE  Standard  for  Modeling  and  Simulation  (M&S)  High  Level  Architecture 
(HLA)  -  Object  Model  Template  (OMT)  2000. 

M&S.5.2  Information  Modeling,  Metadata,  and  Information  Exchange  Standards 

In  addition  to  those  mandated  standards  for  Information  Modeling,  Metadata,  and  Information 
Exchange  Standards  described  in  T8  of  the  JTA,  the  following  mandated  standards  are  applicable  to  the 
Modeling  and  Simulation  Domain. 

M&S.5.2(a)  Emerging.  Synthetic  Environment  Data  Representation  and  Interchange  Specification 
(SEDRIS)  facilitates  interoperability  among  heterogeneous  information  technology  applications  by 
providing  complete  and  unambiguous  interchange  of  environmental  data.  The  range  of  applications 
addressed  in  the  SEDRIS  development  includes  entertainment,  training,  analysis,  and  system 
acquisition  and  support  for  visual,  computer-generated  active  elements,  and  sensor  perspectives. The 
following  SEDRIS  standards  are  emerging  for  M&S  system  use  in  the  exchange  of 
product-independent  environmental  data: 

-  ISO/I  EC  AWI  WD  18024:  SEDRIS  Language  Bindings:  C,  Version  1 ,  21  January  2000. 
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WS.1  Domain  Description 

The  Weapon  Systems  Domain  is  applicable  to  weapon  systems,  which  are  defined  as  a  combination  of 
one  or  more  weapons  with  all  related  equipment,  materials,  services,  personnel,  and  means  of  delivery 
and  deployment  (if  applicable)  required  for  self-sufficiency.1  Weapon  systems  have  special  attributes 
(e.g.,  timeliness,  embedded  nature,  space  and  weight  limitations),  adverse  environmental  conditions, 
and  critical  requirements  (e.g.,  survivability,  low  power/weight,  and  dependable  hard  real-time 
processing)  that  drive  system  architectures  and  make  system  hardware  and  software  highly 
interdependent  and  interrelated.  The  position  of  the  Weapon  Systems  Domain  in  the  Joint  Technical 
Architecture  (JTA)  Hierarchy  Model  is  shown  in  Figure  1-2. 

WS.2  Purpose  and  Scope 

The  purpose  of  this  section  is  to  identify  standards  for  the  Weapon  Systems  (WS)  Domain,  including 
information  standards  and  analogous  standards  applicable  to  weapon  systems. 

The  Weapon  Systems  Domain  encompasses  a  subset  of  the  JTA  and  the  specific  supporting  standards 
profile.  The  family  of  systems  (FoS)  comprised  in  this  domain  has  the  primary  function  of  supporting 
attack  and/or  defense  against  an  adversary.  These  systems  are  intentionally  designed  to  interoperate 
with  other  weapon  systems  and/or  with  systems  external  to  the  Weapon  Systems  Domain. 

For  the  purposes  of  the  JTA,  the  Weapon  Systems  Domain  is  organized  into  subdomains  to  facilitate  the 
identification  of  interoperability  standards  for  common  areas  while  maintaining  the  systems’  primary 
design  function  of  supporting  attack  and/or  defense  against  an  adversary. 

The  inclusion  or  exclusion  of  subdomains  in  the  Weapon  Systems  Domain  is  based  upon  the  domain 
participants’  agreement  to  include  or  exclude  a  candidate.  It  is  important  to  note  that  some  weapon 
systems  incorporate  features/functions  associated  with  more  than  one  domain  or  subdomains  or  are 
integrated,  based  on  operational  requirements,  into  a  ‘system  of  systems’  on  the  battlefield  and 
therefore  developers  must  also  consider  applicable  standards  from  the  pertinent  domains  or 
subdomains.  The  current  Weapon  Systems  subdomains  are: 

□  Aviation  Subdomain  -  Includes  all  Department  of  Defense  (DoD)  weapon  systems  on 
aeronautical  platforms,  except  missiles — manned  and  unmanned,  fixed-wing,  and  rotary-wing. 

□  Ground  Vehicle  Subdomain  -  Includes  all  DoD  weapon  systems  on  moving  ground  platforms, 
except  missiles  and  munition  systems — wheeled  and  tracked,  manned,  and  unmanned. 

□  Missile  Defense  Subdomain  -  Includes  any  system  or  subsystem  (including  associated  Battle 
Management/C4I  systems)  with  a  mission  to  detect,  classify,  identify,  intercept,  and  destroy  or 
negate  the  effectiveness  of  enemy  aircraft  or  missiles  before  launch  or  while  in  flight  so  as  to 
protect  U.S.  and  coalition  forces,  people,  and  geopolitical  assets. 

□  Missile  Systems  Subdomain  -  Includes  Strategic  and  Theater  Ballistic  Missile  Systems,  Cruise 
Missile  Systems,  and  rocket  and  missile  systems  used  in  diverse  Battlefield  Functional  Areas 
including  Fire  Support,  Close  Combat,  and  Special  Operations. 

□  Munition  Systems  Subdomain  -  Includes  unmanned,  remotely  deployed  target  defeating 
systems  that  operate  from  a  fixed  position,  provide/consume  targeting  data,  have  data  links  to 
control  devices,  and  engage  targets  either  autonomously  or  on  demand. 


1  Joint  Publication  1-02,  DoD  Dictionary  of  Military  and  Associated  Terms. 
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□  Soldier  Systems  Subdomain  -  Includes  any  system  or  subsystem  integrating  target  location, 
target  identification,  target  acquisition,  enhanced  survivability,  navigation,  position  location, 
enhanced  mobility,  and  command-and-control  into  a  system  worn  or  canned  by  an  individual 
soldier  in  performance  of  assigned  duties. 

A  domain  is  defined  as  a  distinct  functional  area  that  can  be  supported  by  a  family  of  systems  with 
similar  requirements  and  capabilities.  The  Weapon  Systems  Domain,  in  conjunction  with  the  JTA  Core, 
establishes  the  minimum  set  of  rules  governing  the  application  of  information  technology  between 
weapon  systems,  where  a  weapon  system  is  defined  as  a  combination  of  one  or  more  weapons  with  all 
related  equipment,  materials,  services,  personnel,  and  means  of  delivery  and  deployment  (if  applicable) 
required  for  mission  success.2 3  The  Weapon  Systems  Domain  is  applicable  to  all  weapon  systems 
meeting  that  definition. 

WS.3  Background 

This  domain  follows  the  JTA  Core  document  structure  to  facilitate  the  identification  and  traceability  of 
the  Weapon  Systems  Domain  additions  to  the  standards  mandated  in  the  main  body  of  the  JTA. 
Therefore,  the  Weapon  Systems  Domain  consists  of  three  sections  including:  Domain  Overview, 
Mandated  Standards,  and  Emerging  Standards. 

Weapon  Systems  mandated  standards  result  from  consensus  concerning  the  need  for  the  standards  and 
the  maturity  of  their  commercial  implementations  within  the  Weapon  Systems  Domain  or  within  the 
majority  of  its  subdomains. 

Currently  there  are  sections  within  the  Weapon  Systems  Domain  and  its  subdomains  that  do  not  specify 
mandated  additions  to  the  JTA  Core.  However,  due  to  their  hard  real-time  and  embedded-system 
requirements,  the  Weapon  Systems  Subdomains  are  evaluating  the  available  real-time  standards  for 
possible  mandate  as  additions  to  each  section  of  the  JTA,  where  appropriate. 

WS.3.1  Technical  Reference  Model 

The  Weapon  Systems  Domain  and  subdomains  use  both  the  DoD  Technical  Reference  Model  (TRM) 
Service  View  and  the  Interface  View,  as  described  in  L8.  The  Interface  View  is  more  applicable  to 
real-time  systems.  Services  are  best  described  by  the  TRM  Services  View.  Interface  standardization  in 
weapon  systems  is  a  goal  of  the  Open  Systems  Joint  Task  Force  (OSJTF)  of  DoD.  Both  views  are 
needed  to  capture  all  of  the  standards  required  for  the  Weapon  Systems  Domain  and  subdomains  to 
operate  within  the  DoD  enterprise. 

Figure  1-3  depicts  the  two  distinct  views  of  the  TRM.  Both  views  are  traceable  to  the  POSIX  Open 
Systems  Environment  (OSE)  Reference  Model.  The  Service  View  extends  the  POSIX  model  by 
decomposing  its  entities  into  the  specific  applications  and  services  that  support  DoD  information  and 
computing  systems.  The  Interface  View  is  based  on  the  Generic  Open  Architecture  (GOA)  framework 
(SAE  AS  4893,  1  Jan.  1996)  and  provides  a  context  for  identifying  the  characteristics  of  exchanged 
information  (logical  interfaces)  and  the  method  or  mechanism  used  for  information  transport  (direct 
interfaces).  A  short  explanation  of  the  TRM  is  provided  here;  however,  for  more  detail,  readers  are 
encouraged  to  review  the  TRM  document. 

The  Interface  View  identifies  both  logical  and  direct  interfaces.  A  logical  interface  defines  requirements 
for  peer-to-peer  interchange  of  data.  It  identifies  senders,  receivers,  data  types,  frequency  of  exchange, 
and  formats.  A  direct  interface  identifies  the  characteristics  of  the  information  transfer  medium.  Simply 


2  Ibid. 
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stated,  logical  interfaces  define  what  information  is  transferred;  the  direct  interfaces  define  how  the 
information  is  transferred.  Logical  interfaces  are  implemented  with  direct  interfaces. 

The  Interface  View  expands  the  Application  Platform  entity  within  the  POSIX  model  to  include  the 
three  other  layers:  Systems  Services  Layer  (which  contains  the  Operating  System  Services  and 
extended  Operating  System  Services  secondary  layers),  Resource  Access  Services  Layer,  and  Physical 
Resources  Layer.  The  Interface  View  includes  the  4L,  3L,  2L,  and  1L  for  peer-to-peer  logical  interfaces, 
and  the  4D,  4X,  3X,  3D,  2D,  and  ID  direct  interfaces.  The  Application  Program  Interface  (API)  of  the 
POSIX  model  is  synonymous  with  the  4D  interface,  while  the  External  Environment  Interface  (EEI)  is 
synonymous  with  the  1L  and  ID  interfaces  treated  as  a  pair.  Thus  the  Interface  View  complements  the 
Service  View  by  expanding  the  Application  Platform  entity,  and  by  providing  language  to  describe  both 
application-to-application  logical  interfaces,  and  the  Application  Platform-to-Application  Platform 
logical  interfaces  (3L  and  2L  interfaces). 

The  Service  View,  unlike  the  Interface  View,  categorizes  services  available  in  the  Applications 
Platform.  The  Application  Platform  service  areas  defined  by  the  Service  View  include  both  runtime  and 
pre-runtime  services.  The  Service  View  addresses  only  4D  API  interfaces  and  1D/1L  EEI  interfaces. 
The  Service  View  does  not  address  2L,  3L,  or  4L  peer-to-peer  logical  interfaces,  3X,  3D,  or  2D  direct 
interfaces,  nor  does  it  address  the  Resource  Access  Services  Layer  or  the  Physical  Resources  Layer. 

WS.4  uses  the  Service  View  and  identifies  additions  to  the  JTA  Core  standards,  and  WS.5  uses  the 
layers  identified  in  the  Interface  View  as  a  context  for  classifying  interface  standards  used  in  the  design 
of  weapon  systems  platforms.  WS.4  and  WS.5  both  include  emerging  standards  that  represent  current 
standards  work  within  the  Weapon  Systems  Domain. 

WS.4  JTA  Core-Related  Information  Technology  Categories 

The  following  categories  contain  standards  that  apply  to  mission-area,  support  application,  and 
application  platform  service  software  developed  or  procured  to  process  information  for  weapon 
systems.  These  categories  specify  standards  and,  in  some  cases,  service  areas  that  are  beyond  those  in 
the  JTA  Core,  yet  are  required  for  interoperability  in  the  Weapon  Systems  Domain. 

WS.4.1  Information  Modeling,  Metadata,  and  Information  Exchange  Standards 

This  section  fosters  information  exchange  among  Weapon  Systems  during  their  development  and 
maintenance  phases.  During  concept  exploration  and  development,  a  large  number  of  information 
elements,  objects,  and  artifacts  are  generated.  If  these  elements,  objects,  and  artifacts  are  shared  across 
weapon  system  developments,  considerable  resources  can  be  saved. 

Real-time,  embedded-processing  systems  must  be  developed  within  a  development  support 
environment  for  an  entire  system.  As  such,  they  must  integrate  into  a  systems-engineering  process  that 
culminates  in  prototype  or  production  weapon  systems  that  meet  specific  functional  and  performance 
requirements. 

WS.4.1  (a)  Emerging.  The  following  emerging  standards  are  being  considered  for  mandate  by  the 
Weapon  Systems  Domain  as  an  addition  to  the  JTA  information- modeling  standards: 

-  IEEE  1076:2002,  Standard  VHSIC  Hardware  Description  Language  (VHDL)  Reference 
Manual,  2002.  (VHDL  is  a  high-level  hardware  language). 

-  IEEE  1076.2:  VHDL  Mathematical  Package,  1996. 

-  IEEE  1076.3:  Standard  VHDL  Synthesis  Packages,  1 997. 
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-  IEEE  1076.4:  VITAL  Application-Specific  Integrated  Circuit  (ASIC)  Modeling 
Specification,  2000. 

WS.4.2  Human-Computer  Interface  Standards 

This  section  provides  a  common  framework  for  Human-Computer  Interfaces  (HCI)  design  and 
implementation  in  weapon  systems.  The  objective  is  to  standardize  user  interface  design  and 
implementation  options  across  weapon  systems,  thus  enabling  applications  within  the  Weapon  Systems 
Domain  to  appear  and  behave  consistently,  resulting  in  higher  productivity,  shorter  training  time,  and 
reduced  development,  operation,  and  support  costs  besides  influencing  commercial  HCI  development. 
This  version  mandates  the  design  of  graphical  and  character-based  displays  and  controls  for  weapon 
systems. 

In  order  to  identify  appropriate  systems  to  use  for  baseline  characterization,  the  following  working 
definition  for  time  criticality  is  used:  “Systems  where  no  perceptible  delay  exists  between  the  time  an 
event  occurs  and  the  time  it  is  presented  to  the  user;  and  where  there  is  an  operational  requirement  for 
the  user  to  quickly  recognize  this  presentation,  comprehend  its  significance,  and  determine  and  execute 
appropriate  action(s).  ” 

There  are  some  aspects  of  HCIs  that  can  be  common  across  the  Weapon  Systems  Domain,  while  others 
are  subdomain-specific.  Hence,  an  HCI  style  guide  is  required  at  the  weapon  systems  level,  and 
currently  for  each  subdomain. 

WS.4.2(a)  Emerging.  The  Weapon  Systems  Human-Computer  Interface  (WSHCI)  Style  Guide 
addresses  guidelines  applicable  across  most  or  all  of  the  Weapon  Systems  Domain.  It  provides  a  starting 
point  for  the  development  of  the  subdomain-specific  style  guides  that  will  further  the  goal  of 
standardization.  Also,  the  WSHCI  Style  Guide  provides  design  guidance  based  on  lessons  learned  and 
best  practices  from  past  HCI  efforts.  However,  the  WSHCI  Style  Guide  does  not  provide  the  level  of 
design  guidance  needed  to  attain  a  common  behavior  and  appearance.  This  is  left  to  the 
subdomain-specific  style  guides.  The  following  U.S.  Army  document  is  proposed  as  the  starting  point 
to  become  the  joint  weapon  system  style  guide  and  is  an  emerging  standard: 

-  U.S.  Army  Weapon  Systems  Human-Computer  Interface  (WSHCI)  Style  Guide,  Version  3.0, 
December  1999. 

WS.4.3  Symbology 

Weapon  systems  require  the  use  of  multiple  symbology  standards  to  meet  platform  or  system 
performance  requirements. 

WS.4.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.5  Domain-Specific  Services  and  Interfaces 

This  section  of  the  Weapon  Systems  Domain  specifies  standards  applicable  to  designing  real-time  and 
embedded  hardware/software  computing  systems. 

WS.5.1  Systems  Services  Layer  Interfaces 

The  following  interfaces  arc  System  Service  Layer  Interfaces.  Some  of  these  interfaces  have  multiple 
roles,  such  as  security,  internationalization,  system  management  services,  and  distributed  computing 
services. 
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WS.5.1.1  Operating  Environment  Interface 

Operating  Environment  interfaces  provide  the  core  services  needed  to  operate  and  administer  the 
application  platform  and  provide  an  interface  between  the  application  software  and  the  platform. 
Application  programmers  will  use  operating  environment  interfaces  to  access  operating  system 
functions.  To  separate  sensitive  data  within  an  information  system,  the  kernel  must  include  mechanisms 
to  control  access  to  that  information  and  to  the  underlying  hardware. 

WS.5.1.1  (a)  Emerging.  The  Weapon  Systems  Technical  Architecture  Working  Group  (WSTAWG) 
Operating  Environment  (OE)  Application  Programmer's  Interface  (API)  provides  a  standardized 
interface  to  a  set  of  distributable  objects  that  can  be  utilized  in  the  creation  of  rehostable  distributed  real 
time  embedded  weapon  systems  applications.  This  API  has  been  defined  in  a  scaleable,  extensible, 
language  independent  manner  such  that  it  can  be  tailored  to  application  specific  requirements,  resulting 
in  an  increased  potential  for  application  reuse  throughout  the  weapon  systems  domain.  The  following 
standard  is  emerging: 

-  Weapon  Systems  Technical  Architecture  Working  Group  (WSTAWG)  Operating  Environment 

(OE)  Application  Programmer's  Interface  (API),  Volume  I,  OE  Application  Interface, 

Version  2.0,  1  October  2001. 

For  more  information  on  the  WSTAWG  OE  API,  go  to  http://wstawg.army.mil. 

WS.5.2  Physical  Resources  Layer  Interfaces 

Standards  that  conform  to  the  class  of  interfaces  specified  by  the  Physical  Resources  Layer  of  the  TRM 
interface  view  arc  addressed  in  this  section.  This  section  identifies: 

□  The  interface  standards  that  provide  the  requirements  for  establishing  a  data  interchange 
interface  between  Physical  Resources  and  enable  bus  or  communications  link  boards  to  address 
their  peers  in  another  node  or  system,  and 

□  The  interface  standards  that  support  the  direct  connections  between  Physical  Resources,  such 
as  those  needed  to  enable  buses  and  communications  links  to  address  processors  or  needed  to 
enable  processors  to  address  memory  registers. 

WS.5.2. 1  Parallel  Buses 

A  parallel  bus  is  one  wherein  information  (data,  interrupts,  arbitration,  timing,  etc.)  is  transferred  by 
sending  a  number  of  bits  (such  as  8  or  16)  at  the  same  time  using  multiconductor  cables  and  connectors. 

WS.5.2. 1.1  Single  Board  Computers  (SBCs)  Expansion  Buses 

The  SBC  expansion  bus  is  a  high-speed  I/O  bus  which  allows  microprocessor  to  communicate  with 
external  devices. 

WS.5.2. 1.1  (a)  Emerging.  PCI  (peripheral  component  interface)  is  a  high  speed  local  bus  being  used  by 
several  CICS  and  RISC  microprocessors.  PCI  specification  defines  a  4.2  inch  by  12.3  inch  board  that 
plugs  into  a  motherboard  in  a  perpendicular  fashion.  These  perpendicular  boards  are  not  usable  in  many 
Weapon  Systems  because  they  use  too  much  vertical  space.  The  following  emerging  standard  defines 
the  mechanics  of  a  low  profile  modular  horizontal  mezzanine  card  family  that  uses  the  logical  and 
electrical  layers  of  the  PCI  specification  for  the  local  bus  with  I/O  accessible  via  the  front  panel  and/or 
through  the  connector  to  the  host  computer  for  rear  panel  I/O. 

-  IEEE  1386.1-2001 ,  IEEE  for  a  Common  Mezzanine  Card  Family:  CMC  and  IEEE  Standard 
Physical  and  Environmental  Layers  for  PCI  Mezzanine  Cards:  PMC,  2001. 
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-  ATSC  Document  A/53,  ATSC  Digital  Television  Standard,  16  September  1995. 
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NOTE:  The  standards  and  guidelines  contained  in  this  Subdomain  are  precedent  for  aviation  systems  as 
prepared  by  the  Joint  Aeronautical  Commanders  Group  (JACG),  Aviation  Engineering  Board  (AEB), 
and  Interoperability  Subboard  (ISB). 

WS.AV.1  Aviation  Subdomain  Overview 

The  Aviation  Subdomain  has  been  created  with  the  intention  that  it  will  be  the  principal  reference  for 
Service  Acquisition  Executives,  Program  Executive  Officers,  and  aviation  Program  teams  to  identify 
interoperability  standards  for  aviation  systems.  In  consonance  with  this  reasoning,  all  relevant 
standards  that  are  found  in  higher  tier  sections  (the  Core  and  the  Weapon  Systems  Domain)  of  the  Joint 
Technical  Architecture  (JTA)  have  been  absorbed  into  the  body  of  this  document.  All  standards  in  this 
subdomain  are  designated  “preferred”;  which  means  that  they  should  be  given  first  consideration  while 
addressing  interoperability  requirements  (see  WS.AV.1.5).  These  standards  should  be  applied  in 
consonance  with  Performance-Based  Business  Environment  (PBBE)  principles,  and  within  the  context 
of  the  Performance-Based  Systems  Engineering  Process. 

WS.AV.1. 1  Purpose 

This  subdomain  identifies  preferred  standards  applicable  to  external  (skin-to-skin)  interfaces  for 
Department  of  Defense  (DoD)  aviation  weapon  systems  that  enable  system-to-system  interoperability, 
including  airborne-to-airborne/space/surface  (afloat)/ground  interfaces.  Adoption  of  external  interface 
standards  facilitates  interoperability,  and  is  recognized  as  a  necessary  part  of  the  systems  engineering 
process  to  ensure  that  the  system’s  interoperability  requirements  are  properly  addressed. 

WS.AV.1. 2  Background 

Preferred  standards  listed  in  section  WS.AV.2  of  this  subdomain  are  based  on  work  performed  by  the 
Aviation  Subdomain  Working  Group  (AVSDWG)  for  the  Joint  Aeronautical  Commanders  Group 
Aeronautical  Engineering  Board  Interoperability  Subboard.  AVSDWG  membership  consists  of 
representatives  from  the  military  Services,  the  United  States  Coast  Guard,  the  Federal  Aviation 
Administration,  and  aerospace  industry. 

WS.AV.1. 3  Scope  and  Applicability 

The  Aviation  Subdomain  is  applicable  to  all  DoD  aviation  weapon  systems.  These  include  both 
fixed-wing  and  rotary-wing  aircraft  (manned  and  unmanned),  and  exclude  missiles  and  missile  defense 
systems  (which  are  covered  elsewhere  in  the  Weapon  Systems  Domain  of  the  JTA).  Specifically 
excluded  are  interoperability  standards  that  apply  to  other  JTA  domains/subdomains  such  as  C4I  and 
munitions.  These  standards  do  not  fit  within  the  scope  of  the  JTA  “minimum  set”  concept. 

WS.AV.1. 4  Subdomain  Organization 

This  subdomain  is  divided  into  four  sections:  WS.AV.1,  Overview;  WS.AV.2,  Preferred  Interoperability 
Standards;  WS.AV.3,  Other  JTA  Standards;  and  WS.AV.4,  Terms,  Definitions  and  Acronyms.  Four 
distinct  Aviation  Subdomain  functional  areas  have  been  defined:  Communications,  Data  Links, 
Navigation/Landing  Aids,  and  Identification  Aids.  Aviation  Subdomain  preferred  standards  have  been 
grouped  into  these  four  functional  areas. 

WS.AV.1.5  Preferred  Standards  Selection  Process 

Preferred  standards  have  been  selected  by  the  AVSDWG  in  accordance  with  the  JTA  Aviation 
Subdomain  Preferred  Standards  Selection  Process  (Figure  WS.AV-1).  Standards  were  screened  to 
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ensure  that  they  enable  interoperability  among  and  between  DoD  aviation  weapon  systems,  including 
associated  airbornc-to-airbornc,  space,  surface  (afloat),  and  ground  interface  elements.  The  Aviation 
Subdomain  Preferred  Standards  List  (section  WS.AV.2)  contains  standards  that  meet  interoperability 
requirements  and  meet  the  “best  fit”  ground  rules,  i.e.,  “forward  looking”  and  “open.”  Standards  that  do 
not  meet  interoperability  requirements  and/or  do  not  meet  the  “best  fit”  ground  rules,  but  are  found 
elsewhere  in  the  JTA,  are  regarded  as  “other  JTA  standards”  as  explained  in  section  WS.AV.3.  Only 
systems  and  technologies  that  have  associated  standards  have  been  included. 


vYes 

Aviation 

Subdomain 

Preferred 

Interoperability 

Standards 

List  i) 

‘BEST  FIT’  GROUND  RULES 

Aviation  SubDomain  Preferred  Standards 
Prioritized  Selection  Criteria: 

-  External  Interface 

-  Forward  Looking 

-  Open 

-  Widely  Used 

-  Preferably  International 

-  Preferably  Consensus-Based 

-  Preferably  In  the  Public  Domain 

-  Well  Defined/Verifiable 


Yes 

Other  JTA 

Standards 

_ 7 

Figure  WS.AV-1 :  JTA  Aviation  Subdomain  Preferred  Standards  Selection  Process 
WS.AV.1.5.1  Best  Fit  Ground  Rules 

Aviation  Subdomain  preferred  standards  include  the  minimum  set  of  standards  required  to  enable 
system-to-system  interoperability.  In  addition,  Aviation  Subdomain  preferred  standards  must  also  be 
forward  looking  and/or  open.  Forward  looking  is  considered  a  higher  priority  in  selecting  preferred 
standards.  In  addition,  only  standards  that  address  an  external  interoperability  requirement  are 
considered  for  this  subdomain. 

WS.AV.1. 5.1.1  Forward  Looking 

Forward  looking  standards  are  those  required  to  enable  interoperability  on  future  DoD  aviation  weapon 
systems  and  major  upgrades  to  existing  systems.  Legacy  standards  are  considered  forward  looking  if 
they  are  required  for  future  systems.  If  a  legacy  standard  is  no  longer  required  for  future  aviation 
weapon  systems,  it  would  be  removed  from  the  preferred  list;  however,  it  may  still  meet  specific 
performance-based  requirements. 

WS.AV.1. 5.1 .2  Open 

Open  standards  are  widely  used,  preferably  international,  preferably  consensus-based,  preferably  in  the 
public  domain,  and  well  defined  (verifiable).  To  be  considered  open,  a  standard  does  not  have  to  meet 
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all  criteria  listed.  These  criteria  arc  listed  below  in  priority  order  for  consideration  in  selecting  preferred 
standards. 

WS.AV.1.5.1.2.1  Widely  Used 

Widely  used  is  conceptual  in  nature  and  as  a  result  difficult  to  define.  There  can  be  a  wide  range  of 
users,  from  one  to  thousands.  Typically,  the  concept  requires  some  judgement;  e.g.,  if  there  arc  two 
standards,  and  one  has  a  single  user  and  the  other  has  multiple  users,  the  standard  with  multiple  users 
would  be  preferred. 

WS.AV.1.5.1.2.2  International 

Standards  that  are  accepted  by  more  than  one  nation  or  international  organizations  are  preferred. 

WS.AV.1.5.1.2.3  Consensus  Based 

Consensus  based  means  that  more  than  one  entity,  or  a  standard  development  organization  representing 
more  than  one  entity,  has  agreed  upon  or  promulgated  the  standard. 

WS.AV.1.5.1.2.4  Public  Domain 

Public  domain  means  the  standard  is  not  owned  by  a  single  company  and  is  publicly  available.  Any 
company  could  use  the  standard  without  paying  license  or  royalty  fees. 

WS.AV.1.5.1.2.5  Well  Defined  (Verifiable) 

A  well-defined  standard  contains  readily  available  documentation  that  is  complete  enough  for  use  by  a 
design  team,  and  includes  verification  criteria  to  check  the  design  solution  for  compliance. 

WS.AV.2  Aviation  Subdomain  Preferred  Interoperability  Standards 

This  section  identifies  the  preferred  interoperability  standards  for  the  Aviation  Subdomain.  It  is  divided 
into  four  distinct  service  areas  for  aviation  platform  interoperability:  Communications,  Data  Links, 
Navigation/Landing  Aids,  and  Identification  Aids. 

WS.AV.2. 1  Communications 

WS.AV.2. 1.1  Military  Satellite  Communications 

Military  Satellite  Communications  (MILSATCOM)  systems  include  those  systems  owned  or  leased 
and  operated  by  DoD  and  those  commercial  satellite  communications  (SATCOM)  services  used  by 
DoD.  The  basic  elements  of  satellite  communications  are  a  space  segment,  a  control  segment,  and  a 
terminal  segment  (air,  ship,  ground,  etc.).  An  implementation  of  a  typical  satellite  link  will  require  the 
use  of  satellite  terminals,  a  user  communications  extension,  and  military  or  commercial  satellite 
resources. 

WS.AV.2. 1.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2. 1.2  Radio  Communications 
WS.AV.2. 1.2.1  High  Frequency 

WS.AV.2. 1.2. 1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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WS.AV.2. 1.2.2  Very  High  Frequency 

WS.AV.2.1. 2.2(a)  Emerging.  The  following  standards  are  emerging  for  radio-subsystem  requirements 
operating  in  the  Very  High  Frequency  (VHF)  bands: 

-  MIL-STD-1 88-241 ,  RF  Interface  Requirements  for  VHF  Frequency  Hopping  Tactical  Radio 
Systems.  This  standard  identifies  the  anti-jamming  capabilities  for  VHF  radio  systems.  This  is 
a  classified  document  currently  under  development  (no  date  yet). 

WS.AV.2. 1.2.3  Ultra  High  Frequency 

WS.AV.2.1. 2.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2.1. 2.4  Combat  Net  Radio 

The  Combat  Net  Radio  (CNR)  network  supports  the  Army  battlefield.  It  uses  existing  radio  waveforms 
to  physically  transmit  the  data  for  airborne  and  mobile  ground  users. 

WS.AV.2.1. 2.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2.1 .2.5  Global  Air  Traffic  Management  -  Communications 

This  section  addresses  civil  Air  Traffic  Management  (ATM)  interoperability  for  DoD  aircraft  in  order 
to  operate  in  the  evolving  global  civil  aviation  airspace  arena.  This  evolution  is  the  result  of  the 
International  Civil  Aviation  Organization  (ICAO),  and  its  associated  Civil  Aviation  Authorities’ 
(CAAs’)  desires  to  take  advantage  of  advancements  in  the  areas  of  communications,  navigation,  and 
surveillance  (CNS)  technologies.  The  purpose  is  to  move  from  a  system  of  ground-based  air  traffic 
control  to  an  integrated  system  of  ATM.  As  a  result,  DoD  aircraft  must  conform,  where  required,  to 
appropriate  civil  requirements  and  industry  standards  to  meet  future  civil  airspace  requirements.  These 
aircraft  must  be  properly  equipped  to  operate  in  the  defined  civil  aviation  regulated  airspace 
environment,  and  accommodate  its  evolution.  If  not,  they  will  be  unable  to  operate  safely  and 
effectively  in  airspace  in  which  new  separation  standards  and  ATM  procedures  are  being  implemented 
by  civil  aviation  authorities.  Such  aircraft  may  be  provided  passage  in  the  airspace  but  may  encounter 
non-optimal  routes  and  traffic  delays  according  to  Euro  Control  documents  or  may  be  excluded  from 
operating  in  that  airspace.  The  focus  of  this  section  is  on  communications  and  information-transfer 
standards  for  civil  ATM  interoperability. 

WS.AV.2.1. 2.5(a)  Emerging.  The  following  standards  are  emerging  in  this  area: 

-  ICAO  Annex  1 0,  Volume  III,  International  Standards  and  Recommended  Practices  (SARPs)  for 
High  Frequency  Data  Link  (HFDL),  July  1995. 

WS.AV.2.1. 2.5.1  Traffic  Information 

WS.AV.2.1. 2.5.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2.1. 2.5.2  Area  Navigation 

WS.AV.2.1. 2.5.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2.2  Data  Links 
WS.AV.2.2.1  Link  4A 

Link  4A  is  used  in  combat  direction  systems  and  Link  4A  controlled  aircraft.  It  is  also  used  for  aircraft 
earner  deck  landings  (Navy  only). 

WS.AV.2.2.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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WS.AV.2.2.2  Link  11 

This  data  link  is  for  communicating  with  tactical  data  systems  of  U.S.  and  allied  forces. 
WS.AV.2.2.2(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.2.3  Link  16 

WS.AV.2.2.3(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3  Navigation/Landing  Aids 
WS.AV.2.3.1  Global  Positioning 

The  CJCS  (CJCSI  6130.01A,  1998  CJCS  Master  Positioning,  Navigation,  and  Timing  Plan)  has 
declared  that  the  GPS  will  be  the  primary  radio  navigation  source  of  positioning,  navigation  and  timing 
(PNT)  for  the  DoD.  GPS  is  a  space-based,  worldwide,  precise  positioning,  velocity,  and  timing  system. 
It  provides  an  unlimited  number  of  suitably  equipped  passive  users  with  a  force-enhancing, 
common-grid,  all-weather,  continuous,  three-dimensional  PNT  capability. 

WS.AV.2.3.1  (a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3. 1.1  Global  Air  Traffic  Management  -  Navigation 

The  civil  global  navigation  standards  provide  interoperability  for  DoD  aircraft  to  navigate  and  land  in 
the  evolving  global  civil  aviation  airspace  arena.  Two  types  of  global  navigation  satellite  augmentation 
have  been  standardized  by  ICAO  -  the  Space-Based  Augmentation  System  (SBAS)  and  the 
Ground-Based  Augmentation  System  (GBAS).  These  arc  known  in  the  United  States  as  Wide  Area 
Augmentation  System  (WAAS)  and  Local  Area  Augmentation  System  (LAAS),  respectively. 
Interoperability  standards  include  ICAO  Annex  10  documentation  and  RTCA  standards  as  well  as 
specific  operational  approval  documents  such  as  FAA  Advisory  Circulars  (AC).  Compliance  or 
equivalence  with  these  standards  is  necessary  for  authorized  IFR  operations. 

WS.AV.2.3. 1.1  (a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3. 2  Tactical  Area  Navigation 

WS.AV.2.3.2(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3.3  Airborne  Radio  Marker 

WS.AV.2.3.3(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3.4  Landing  Aids 
WS.AV.2.3.4.1  Instrument  Landing  Aids 

WS.AV.2.3.4.1(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3. 4. 2  Microwave  Landing  Aids 

WS.AV.2.3.4.2(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3.4.3  GPS  Landing  Aids 

WS.AV.2.3.4.3(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.AV.2.3. 4. 4  Multimode  Landing  Aids 

WS.AV.2.3.4.4(a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 
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WS.AV.2.4  Identification  Aids 
WS.AV.2.4.1  Identification  Friend  or  Foe 

The  primary  function  of  Identification  Friend  or  Foe  (IFF)  is  to  establish  the  identity  of  all  friendly 
systems  within  the  surveillance  volume  of  surface-to-air,  air-to-air,  and  some  air-to-ground  weapon 
systems.  The  need  for  friend  identification  is  to  permit  tactical  action  against  all  foe  (non-friendly) 
systems  and  to  avoid  tactical  action  against  friendly  systems.  This  need  is  a  key  element  in  modern 
combat,  as  an  object  detected  by  a  sensor,  even  beyond  visual  range,  has  to  be  identified  and  classified 
as  early  as  possible.  This  is  so  that,  if  necessary,  either  an  appropriate  defense  can  be  prepared  against 
the  foe  or  that  steps  can  be  taken  to  prevent  the  friend  from  being  engaged/attacked  by  friendly  forces. 

WS.AV.2.4.1  (a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2.4.2  Traffic  Alert  and  Collision  Avoidance 
WS.AV.2.4.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.2.4.3  Automatic  Dependent  Surveillance  -  Broadcast 
WS.AV.2.4.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.AV.3  Aviation  Subdomain  “Other  JTA”  Standards 

All  JTA  Standards  not  listed  in  the  Aviation  Subdomain  Preferred  Standards  list  (sections  WS.AV.2.1  - 
WS.AV.2.4)  are  “other  JTA”  standards.  The  use  of  other  JTA  standards  on  DoD  aviation  weapon 
systems  is  encouraged  when  a  standard  can  meet  a  stated  or  derived  requirement.  (See  step  3  of  the 
Preferred  Standards  Selection  Process.) 

WS.AV.4  Aviation  Subdomain  Terms,  Definitions  and  Acronyms 

The  following  terms  have  not  been  sufficiently  defined  elsewhere,  or  are  easily  misunderstood.  Their 
definitions  appear  here  for  clarification. 

WS.AV.4.1  Performance-Based  Business  Environment  (PBBE) 

PBBE  is  a  “state  of  being”  where  government  customers  and  contractors/suppliers  jointly  capitalize  on 
commercial  practice  efficiencies  to  improve  the  acquisition  and  sustainment  environment.  In  this  new 
environment,  solicitations  and  contracts  describe  system  performance  requirements  in  a  way  that 
permits  contractors  greater  latitude  than  under  historical  acquisition  methods  to  use  then-  own  design 
and  manufacturing  ingenuity  to  meet  needs.  Additionally,  suppliers  will  compete  and  be  selected  based 
on  their  proposed  approaches,  process  effectiveness,  and  prior  performance. 

WS.AV.4.2  Verifiable 

Verification  includes  substantiation  that  performance  requirements  have  been  satisfied  as  well  as 
confirmation  that  delivered  products  exhibit  functionally  equivalent  performance  to  the  qualified 
design.  This  is  accomplished  through  the  use  of  product  acceptance  criteria  that  are  developed  as  part 
of  the  engineering  development  effort.  Interface  standards  should  include  rigorously  defined 
verification  criteria.  For  electronics  and  software,  a  “gold  standard”  is  often  used  to  verify  that 
performance  requirements  have  been  achieved. 
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WS.GV.1  Subdomain  Description 

Identify  information  and  analogous  standards  applicable  to  ground  vehicle  systems.  Systems  covered 
within  the  Ground  Vehicle  Subdomain  include  all  Department  of  Defense  (DoD)  weapon  systems  on 
moving  ground  platforms — wheeled  and  tracked  (except  missiles),  manned  and  unmanned. 

WS.GV.2  Purpose  and  Scope 

This  subdomain  specifies  standards  needed  for  interoperability  between  Ground  Vehicles  and  other 
DoD  systems. 

WS.GV.3  Background 

The  standards  in  this  subdomain  are  based  on  the  work  performed  by  the  Army  Weapons  Systems 
Technical  Architecture  Working  Group  (WSTAWG). 

WS.GV.4  Subdomain-Specific  Services  and  Interfaces 

The  Interfaces  View  of  the  Technical  Reference  Model  (TRM),  depicted  in  Figure  1-3,  provides 
sufficient  fidelity  for  identifying  classes  of  interfaces  to  apply  open  systems  interface  standards  to  the 
design  of  real-time  and  embedded  hardware/software  systems.  The  Interface  View  also  facilitates  the 
identification  of  critical  functions  and  interfaces  within  the  real-time  and  embedded-computing  systems 
of  the  Ground  Vehicles  Subdomain.  This  section  provides  a  common  framework  identifying  mandated 
and  emerging  embedded-computing  interface  standards  associated  with  the  logical  and  direct  interface 
classes  defined  for  the  layers  depicted  in  the  Interfaces  View  of  the  TRM.  Only  those  layers  of  the  TRM 
that  have  subdomain-specific  mandated  or  emerging  standards  identified  are  addressed  in  this  section. 

WS.GV.4.1  Application  Software  Layer  Interfaces 

The  Application  Software  Layer  Interfaces  provide  a  set  of  resources  that  support  the  services  on  which 
application  software  will  execute.  It  provides  interfaces  to  services  that,  as  much  as  possible,  make  the 
implementation  specific  characteristics  of  the  platform  transparent  to  the  application  software. 

WS.GV.4.1  (a)  Emerging.  The  Sensor  Link  Protocol  Message  Set  (SLP)  was  developed  for  use  as  a 
common  interface  between  electro-optical  sensor  systems  and  a  diverse  set  of  host  computer  systems. 
The  SPL  message  set  is  decoupled  from  lower  layer  protocols  to  allow  implemented  the  flexibility  to 
select  from  a  number  of  open  standards  such  as  RS-232/485,  FireWire  or  Universal  Serial  Bus  (USB). 
The  SLP  message  set  is  used  in  conjunction  with  the  SLP  Interface  Control  Document  to  develop  a 
common  digital  data  exchange  mechanism  between  sensors  and  host  computing  devices  that  offer  full 
remote  operation  and  control  of  those  sensors  by  a  host  computing  device  in  both  a  point-to-point  and 
networked  environment.  The  following  emerging  standard  defines  the  SLP  message  set: 

-  SLP-MSG-210,  Revision,  Sensor  Link  Protocol  Message  Set,  26  March  2001 . 

WS.GV.4.2  System  Services  Layer  Interfaces 

The  following  interfaces  are  System  Service  Layer  Interfaces.  Some  of  these  interfaces  have  multiple 
roles,  such  as  security,  internationalization,  system  management  services,  and  distributed  computing 
services. 
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WS.GV.4.2.1  Operating  Environment  Interface 

The  Operating  Environment  (OE)  Application  Programmer’s  Interface  (API)  provides  a  standardized 
interface  to  a  set  of  distributable  objects  that  can  be  utilized  in  the  creation  of  rehostable  distributed  real 
time  embedded  weapon  systems  applications.  This  API  has  been  defined  in  a  scaleable,  extensible, 
language  independent  manner  such  that  it  can  be  tailored  to  application  specific  requirements,  resulting 
in  an  increased  potential  for  application  reuse  throughout  the  Weapon  System  Domain. 

WS.GV.4.2.1  (a)  Emerging.  There  arc  no  emerging  standards  in  this  area. 

WS.GV.4.3  Physical  Resources  Layer  Interfaces 

Standards  that  conform  to  the  class  of  interfaces  specified  by  the  Physical  Resources  Layer  of  the  TRM 
interface  view  are  addressed  in  this  section.  This  section  identifies: 

□  The  interface  standards  that  provide  the  requirements  for  establishing  a  data  interchange 
interface  between  Physical  Resources  and  enable  bus  or  communications  link  boards  to  address 
their  peers  in  another  node  or  system,  and 

□  The  interface  standards  that  support  the  direct  connections  between  Physical  Resources,  such 
as  those  needed  to  enable  buses  and  communications  links  to  address  processors  or  needed  to 
enable  processors  to  address  memory  registers. 

WS.GV.4.3. 1  Serial  Buses 

Serial  Buses  are  buses  that  transmit  information  one  bit  at  a  time  in  a  sequential  or  serial  manner. 

WS.GV.4.3. 1(a)  Emerging.  Ground  vehicle  systems  is  also  evaluating  the  Controller  Area  Network 
Bus  (CANBUS)  protocol  and  Class  C  networks  documented  in  SAE  J 1939  as  an  emerging  standard  for 
use  in  its  heavy  trucks  and  off  road  vehicles: 

-  SAE  J1939,  Recommended  Practice  for  a  Serial  Control  and  Communications  Vehicle 
Network,  April  2000. 

SAE  J1587  defines  the  format  of  the  messages  and  data  being  communicated  between  microprocessors 
used  in  heavy-duty  vehicle  applications.  It  is  meant  to  serve  as  a  guide  toward  standard  practice 
software  compatibility  among  microcomputer-based  modules.  This  standard  is  to  be  used  with  SAE 
J1708,  which  defines  the  requirements  for  the  hardware  and  basic  protocol  needed  to  implement  the 
requirements  of  SAE  J1587.  The  following  information  transfer  standard  is  emerging  for  ground 
vehicles: 

-  SAE  J1587,  Joint  SAE/TMC  Electronic  Data  Interchange  Between  Microcomputer  Systems  in 
Heavy-duty  Vehicle  Applications,  July  1998. 

SAE  J1708  defines  a  general-purpose  serial  data  communications  link  that  may  be  utilized  in 
heavy-duty  vehicle  applications.  It  is  intended  to  serve  as  a  guide  toward  standard  practice  to  promote 
serial  communication  compatibility  among  microcomputer-based  modules.  This  standard  requires  the 
definition  of  the  data  format,  message  identification,  message  priorities,  error  detection  (and 
correction),  maximum  message  length,  percent  bus  utilization,  and  methods  of  physical 
adding/removing  units  to/from  the  line  for  the  particular  application.  The  following  information 
transfer  standard  is  emerging  for  ground  vehicles: 

-  SAE  J1708,  Serial  Data  Communications  Between  Microcomputer  Systems  in  Heavy-duty 
Vehicle  Applications,  October  1993. 
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The  Digital  Visual  Interface  (DVI)  Specification  Revision  1.0,  02  April  1999,  developed  by  the  Digital 
Display  Working  Group  (DDWG)  defines  a  high-speed  digital  connection  for  providing  the  distribution 
of  visual  data  information  between  a  processor  element  and  a  display  device.  This  specification  is 
meant  to  serve  as  a  guide  toward  standard  practice  information  exchange  among  microcomputer  based 
modules.  The  following  specification  is  emerging  for  Ground  Vehicles: 

-  Digital  Visual  Interface  (DVI),  Digital  Display  Working  Group  (DDWG),  Revision  1 .0, 

02  April  1999. 

WS.GV.4.3.2  Parallel  Buses 

A  parallel  bus  is  one  wherein  information  (data,  interrupts,  arbitration,  timing,  etc.)  is  transferred  by 
sending  a  number  of  bits  (such  as  8  or  16)  at  the  same  time  using  multiconductor  cables  and  connectors. 

WS.GV.4.3.2. 1  Backplane  Buses 

Backplane  buses  are  designed  to  allow  processors,  memory,  and  I/O  devices  to  coexist  on  a  single  bus; 
they  balance  the  demands  of  processor-memory  communication  with  the  demands  of  I/O 
device-memory  communication.  Backplane  buses  received  their  name  because  they  were  often  built  in 
the  backplane,  an  interconnection  structure  within  the  chassis;  processor,  memory,  and  I/O  boards 
would  then  plug  into  the  backplane  using  the  bus  for  communication. 

WS.GV.4.3.2. 1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.GV.4.3.2.2  I/O  Buses 

I/O  buses  can  be  lengthy,  can  have  many  types  of  devices  connected  to  them,  and  often  have  a  wide 
range  in  the  data  bandwidth  of  devices  connected  to  them.  I/O  buses  do  not  typically  interface  directly 
to  the  memory  but  use  either  a  processor-memory  or  a  backplane  bus  to  connect  to  memory. 

WS.GV.4.3.2.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.GV.4.3.2.3  Single  Board  Computers  (SBCs)  Expansion  Buses 

The  SBC  expansion  bus  is  a  high-speed  I/O  bus  which  allows  microprocessors  to  communicate  with 
external  devices. 

WS.GV.4.3 .2.3(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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WS.MD:  Missile  Defense  Subdomain 

WS.MD.1  Subdomain  Description 

Systems  covered  within  the  Missile  Defense  Subdomain  include  any  system  or  subsystem  (including 
associated  Ballistic  Missile/C4I  systems)  with  a  mission  to  detect,  classify,  identify,  intercept,  and 
destroy  or  negate  the  effectiveness  of  enemy  aircraft  or  missiles  before  launch  or  while  in  flight  so  as  to 
protect  U.S.  and  coalition  forces,  people,  and  geopolitical  assets.  Missile  defense  systems  typically 
include  one  or  more  sensors,  one  or  more  weapons,  and  a  communication  infrastructure  all  coordinated 
by  a  Battle  Management  Command,  Control,  and  Communications  (BMC3)  system  (which  also 
coordinates  with  external  systems).  At  this  time  there  is  ongoing  work  to  develop  a  tailored  reference 
model  and  technical  architecture  profile  for  missile  defense  based  on  the  Technical  Reference  Model 
(TRM). 

WS.MD.2  Purpose  and  Scope 

There  is  a  need  for  interoperability  among  lower  tier  missile  defense  systems,  upper  tier  missile  defense 
systems,  and  other  systems  such  as  space-based  sensors  to  support  the  overall  mission  of  missile 
defense.  Such  interoperability  would  need  to  support  activities  such  as  minimum  cueing,  track 
exchange,  and  weapon  coordination.  This  requires  standards  to  deal  with  how  information  should  be 
transferred  (e.g.,  geospatial  values).  This  JTA  subdomain  specifies  such  standards  to  support 
interoperability  to  fulfill  missile-defense  mission  objectives. 

The  scope  of  this  subdomain  is  the  entire  domain  of  missile  defense.  However,  the  standards  listed 
within  this  version  of  the  subdomain  solely  address  support  for  active  and  passive  defense1  against 
theater  and  strategic  ballistic  missiles  in  flight,  as  a  first  step  in  evolving  a  comprehensive  and  complete 
set  of  standards  for  all  missile  defense  systems.  It  is  acknowledged  that  this  evolution  will  require 
interaction  with  many  communities  to  resolve  standardization  issues. 

WS.MD.3  JTA  Core-Related  Information  Technology  Categories 

This  section  identifies  standards  for  the  Missile  Defense  Subdomain  that  are  additional  to  standards  in 
the  JTA  Core  to  promote  interoperability  within  the  Missile  Defense  Subdomain. 

WS.MD.3. 1  Navigation 

Missile  defense  system  interoperability,  which  is  necessary  to  increase  mission  effectiveness,  requires 
accurate  agreements  on  navigation-related  data. 

WS.MD.3. 1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.MD.3.2  Time  Synchronization 

The  time  basis  for  missile  defense  operations  shall  be  UTC  USNO  as  disseminated  by  the  Navstar 
Global  Positioning  System  (GPS). 

WS.MD.3.2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 


1  Missile  defense  can  be  viewed  as  having  four  pillars:  active  defense,  attack  operations,  passive  defense,  and  an  overarching 
BMC4I.  In  this  context,  active  defense  is  direct  defensive  action  taken  to  nullify  or  reduce  the  effectiveness  of  hostile  air  action, 
such  as  the  use  of  missile  defense  weapons.  Attack  operations  includes  activities  such  as  directly  attacking  missile  launchers. 
Passive  defense  is  all  other  measures  taken  to  minimize  the  effectiveness  of  a  specific  hostile  air  action,  including  deception 
and  dispersion.  The  overarching  BMC4I  directs  and  coordinates  all  these  activities. 
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WS.MD.3.3  Information  Transfer  Standards 

This  section  identifies  the  information  transfer  standards  required  for  interoperability  among 
Department  of  Defense  (DoD)  missile  defense  systems. 

WS.MD.3.3(a)  Emerging.  The  Joint  Range  Extension  (JRE)  application  protocol  (JREAP) 
encapsulates  TADIL  information  (e.g.,  TADIL-J/Link-16)  as  an  application  layer  within  Joint 
Technical  Architecture  (JTA)  compliant  data  protocols  (e.g.,  Internet  Protocol  (IP),  Point-to-Point 
Protocol  (PPP),  Ultra  High  Frequency  Demand  Assigned  Multiple  Access  [UHF  DAMA]).  The  joint 
protocol  allows  a  JRE  Gateway  to  process  and  manage  incoming  TADIL  messages  and  redirect  them  to 
the  appropriate  destination  via  the  appropriate  media.  The  following  standard  is  emerging  for  exchange 
of  TADIL-J  information  over  long-haul  media: 

-  M1L-STD-3011 ,  Interoperability  Standard  for  Joint  Range  Extension  Application  Protocol 
(JREAP),  Defense  Information  Systems  Agency  (DISA),  Information  Exchange  Management 
Panel  (IXMP),  30  September  2002. 

WS.MD.3.4  Bit-Oriented  Formatted  Messages 

The  Tactical  Digital  Information  Link  (TADIL)-J/Link-16  message  format  is  mandated  as  a  mobile 
interoperable  communication  message  format  on  all  transportable  missile  defense  systems,  and  for 
Theater  Air  Missile  Defense  (TAMD)  systems  that  must  interoperate  with  them.  This  is  specified  by 
MIL-STD-6016A  combined  with  all  accepted  Interface  Change  Proposals  (ICPs)  awaiting 
incorporation.  Although  this  standard  is  in  the  JTA  Core,  this  subdomain  adds  the  additional 
requirement  that  this  standard  must  be  implemented  for  such  systems  and  cannot  be  replaced  with  the 
alternatives  listed  in  the  JTA  Core.  Such  systems  may  also  support  other  message  formats. 

WS.MD.3.4(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.MD.3.5  Missile  Defense  Data  Element  Descriptions 

The  Missile  Defense  Agency  through  the  Data  Interoperability  and  Standardization  Steering  Group 
(DISSG)  is  developing  a  Data  Element  Descriptions  (DED)  document  for  Interoperability.  This  DED  is 
composed  of  data  elements  selected  from  the  TADIL-J  Message  Standard  and  the  Variable  Message 
Format  (VMF)-based  message  set  for  the  Ground-based  Midcourse  Defense  System.  The  data  elements 
were  selected  for  the  DED  based  on  the  need  for  sharing  this  information  between  and  among 
operational  elements  of  Missile  Defense  Systems. 

There  is  ongoing  work  through  the  Data  Element  and  Exchange  Rule  Working  Group  (DEER  WG),  the 
working  group  under  the  DISSG,  to  define  the  objective  data  elements  and  exchange  rules  for  the  DED 
to  promote  information  sharing  across  the  Missile  Defense  community.  By  identifying  and  controlling 
objective  data  elements  that  are  key  to  interoperability  for  new  systems,  as  well  as  providing 
appropriate  exchange  rules  for  those  data  elements  when  used  by  legacy  systems,  current  and  future 
message  set  developers  will  be  confident  that  they  have  selected  data  elements  that  can  be  used  and 
properly  shared  within  Missile  Defense. 

WS.MD.3.5(a)  Emerging.  The  following  standard  is  emerging: 

-  Ballistic  Missile  Defense  Interoperability  Data  Element  Descriptions  (BMD-I  DED),  Ballistic 
Missile  Defense  Organization,  Version  3,  28  September  2001. 
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WS.MS.1  Subdomain  Description 

Systems  covered  within  the  Missile  Systems  Subdomain  include  Strategic  and  Theater  Ballistic  Missile 
Systems;  Cruise  Missile  Systems;  and  rocket  and  missile  systems  used  in  diverse  Battlefield  Functional 
Areas  including  Fire  Support,  Close  Combat,  and  Special  Operations.  Note  that  Missiles  which  are 
components  of  U.S.  National  and  Theater  Missile  Defense  systems  are  not  included  in  the  Missile 
Systems  Subdomain,  but  instead  are  covered  in  the  Missile  Defense  Subdomain.  The  diversity  of 
missions  that  missile  systems  must  perform  induces  a  variety  of  system  solutions  including 
shoulder- fired,  line-of-sight  direct  fire,  and  non-line-of-sight  indirect  fire  missiles  and  rockets; 
ground-launched,  air-launched,  and  ship-launched  or  submarine-launched  cruise  missiles; 
surface-to-surface,  surface-to-air,  ship-to-ship,  air-to-air,  and  air-to-ground  missiles;  and 
Inter-Continental,  Intermediate  Range,  and  Submarine-Launched  Ballistic  Missiles  (ICBMs,  IRBMs, 
and  SLBMs  respectively). 

WS.MS.2  Purpose  and  Scope 

This  subdomain  builds  on  the  Weapon  Systems  Domain  by  identifying  Missile  Systems 
Subdomain-specific  standards  including  information  standards  and  analogous  standards  applicable  to 
Missile  Systems.  (See  1.7.3  for  relationships  between  Core,  Domain,  and  Subdomain  standards.) 

The  scope  of  this  subdomain  is  all  Department  of  Defense  (DoD)  Missile  Systems  as  defined  above. 
Flowever,  the  standards  listed  in  this  subdomain  currently  address  only  Army  Missile  and  Rocket 
Systems.  This  is  a  first  step  in  evolving  a  comprehensive  and  complete  set  of  standards  for  Missile 
Systems  for  all  the  Services.  It  is  acknowledged  that  this  evolution  will  require  extensive  interaction 
with  many  communities  to  resolve  standardization  issues. 

WS.MS.3  Background 

Broadly,  Missile  Systems  may  be  described  in  terms  of  the  following  subsystems:  1)  missile, 

2)  launcher,  3)  C3I  (including  fire  control  or  battle  management),  and,  in  some  cases,  4)  sensor.  These 
subsystems  are  designed  and  developed  to  deploy  and  function  as  a  single  Missile  System  in  which  all 
the  subsystems  are,  to  a  certain  degree,  interdependent.  The  Missile  System  may  have  all  of  the 
subsystems  collocated  or  distributed.  For  example,  a  sensing  device  may  be  onboard  a  missile  or  on  the 
ground,  in  the  air,  or  in  space  providing  information  to  the  missile  via  a  high-performance  data  link. 
Also,  a  missile’s  fire  control  or  battle  management  system  may  be  collocated  in  the  launch  vehicle  or 
geographically  separate  from  the  launch  vehicle,  but  connected  through  a  direct  (physical), 
line-of-sight,  or  non-line-of-sight  communications  link. 

WS.MS.4  JTA  Core-Related  Information  Technology  Categories 

This  section  identifies  standards  for  the  Missile  Systems  Subdomain  that  are  additional  to  standards  in 
the  JTA  Core  to  promote  interoperability  within  the  Missile  Systems  Subdomain. 

WS.MS.4. 1  Information  Processing  Standards 

This  section  specifies  the  information  processing  standards  that  the  DoD  will  use  to  develop 
interoperable  missile  systems  that  support  warfighter  operations. 


JTA  Version  6.0,  Final 
3  October  2003 


Vol.  11-126 


WS.MS:  Missile  Systems  Subdomain 


WS.MS.4.1.1  Geospatial  Data  Interchange 

Geospatial  services  are  also  referred  to  as  mapping,  charting,  and  geodesy  (MC&G)  services.  This 
section  specifies  the  standards  to  be  implemented  to  ensure  seamless  exchange  of  geospatial  data  across 
DoD  missile  systems. 

WS.MS.4.1.1  (a)  Emerging.  The  following  standard  is  being  evaluated  as  an  emerging  extension  to  the 
WGS  84  geospatial  data  interchange  standard  for  use  with  Missile  Systems: 

-  ANSI/AIAA  R-004-1992,  Recommended  Practice  for  Atmospheric  and  Space  Flight  Vehicle 
Coordinate  Systems. 

WS.MS.4.2  Information  Transfer  Standards 

This  section  identifies  the  information  transfer  standards  required  for  interoperability  between  DoD 
missile  systems. 

WS.MS.4.2(a)  Emerging.  The  Joint  Range  Extension  (JRE)  Application  Protocol  (JREAP) 
encapsulates  TADIL  information  (e.g.,  TADIL-J/Link- 1 6)  as  an  application  layer  within  Joint 
Technical  Architecture  (JTA)  compliant  data  protocols  (e.g.,  Internet  Protocol  (IP),  Point-to-Point 
Protocol  (PPP),  Ultra  High  Frequency  Demand  Assigned  Multiple  Access  (UHF  DAMA)).  The  joint 
protocol  allows  a  JRE  Gateway  to  process  and  manage  incoming  TADIL  messages  and  redirect  them  to 
the  appropriate  destination  via  the  appropriate  media. 

The  following  standard  is  emerging  for  exchange  of  TADIL-J  information  over  long  haul  media: 

-  MIL-STD-3011 ,  Interoperability  Standard  for  Joint  Range  Extension  Application  Protocol 
(JREAP),  Defense  Information  Systems  Agency  (DISA),  Information  Exchange  Management 
Panel  (IXMP),  30  September  2002. 

WS.MS.5  Subdomain-Specific  Services  and  Interfaces 

The  Interfaces  View  of  the  Technical  Reference  Model  (TRM),  depicted  in  Figure  1-3,  provides 
sufficient  fidelity  for  identifying  classes  of  interfaces  to  apply  open  systems  interface  standards  to  the 
design  of  real-time  and  embedded  hardware/software  systems.  The  Interface  View  also  facilitates  the 
identification  of  critical  functions  and  interfaces  within  the  real-time  and  embedded-computing  systems 
of  the  Missile  Systems  Subdomain.  This  section  provides  a  common  framework  identifying  mandated 
and  emerging  embedded-computing  interface  standards  associated  with  the  logical  and  direct  interface 
classes  defined  for  the  layers  depicted  in  the  Interfaces  View  of  the  TRM.  Only  those  layers  of  the  TRM 
that  have  subdomain-specific  mandated  or  emerging  standards  identified  are  addressed  in  this  section. 

WS.MS.5. 1  Physical  Resources  Layer  Interfaces 

Standards  that  conform  to  the  class  of  interfaces  specified  by  the  Physical  Resources  Layer  of  the  TRM 
interface  view  are  addressed  in  this  section.  This  section  identifies: 

□  The  interface  standards  that  provide  the  requirements  for  establishing  a  data  interchange 
interface  between  Physical  Resources  and  enable  bus  or  communications  link  boards  to  address 
their  peers  in  another  node  or  system,  and 

□  The  interface  standards  that  support  the  direct  connections  between  physical  resources,  such  as 
those  needed  to  enable  buses  and  communications  links  to  address  processors  or  those  needed 
to  enable  processors  to  address  memory  registers. 
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WS.MS.5.1.1  Serial  Buses 

Serial  buses  are  buses  that  transmit  information  one  bit  at  a  time  in  a  sequential  or  serial  manner. 

WS.MS.5.1.1  (a)  Emerging.  The  MIL-STD-1553B  data  bus  standard  will  be  used  by  applications 
requiring  digital,  command/response,  time  division  multiplexing  techniques  and  defines  the  data  bus 
line  and  its  interface  electronics,  the  concept  of  operation  and  information  flow  on  the  multiplex  data 
bus,  and  the  electrical  and  functional  formats  to  be  employed.  The  following  standard  is  emerging: 

-  MIL-STD-1553B,  Interface  Standard  for  Digital  Time  Division  Command/Response  Multiplex 
Data  Bus,  21  September  1978,  with  Notice  of  Change  1,12  February  1980,  Notice  of 
Change  2,  8  September  1986,  Notice  of  Change  3,  31  January  1993,  and  Notice  of  Change  4, 
15  January  1996. 

WS.MS.5.1.2  Parallel  Buses 

A  parallel  bus  is  one  wherein  information  (data,  interrupts,  arbitration,  timing,  etc.)  is  transferred  by 
sending  a  number  of  bits  (such  as  8  or  16)  at  the  same  time  using  multiconductor  cables  and  connectors. 

WS.MS.5. 1.2.1  Backplane  Buses 

Backplane  buses  are  designed  to  allow  processors,  memory,  and  I/O  devices  to  coexist  on  a  single  bus; 
they  balance  the  demands  of  processor-memory  communication  with  the  demands  of  I/O 
device-memory  communication.  Backplane  buses  received  their  name  because  they  were  often  built  in 
the  backplane,  an  interconnection  structure  within  the  chassis;  processor,  memory,  and  I/O  boards 
would  then  plug  into  the  backplane  using  the  bus  for  communication. 

WS.MS.5.1.2.1(a)  Emerging.  The  VME  64  standard  defines  a  framework  for  8-,  16-,  32-,  and  64-bit 
parallel  bus  computer  architectures  that  can  implement  single  and  multiprocessor  systems.  It  is  based 
on  the  VMEbus  specification  released  by  the  VMbus  Manufacturer  2s  Group  (now  VITA)  in 
August  1982  and  includes  the  initial  four  basic  subbuses:  (1)  data  transfer  bus,  (2)  priority  interrupt  bus, 
(3)  arbitration  bus,  and  (4)  utility  bus.  The  following  standards  are  emerging: 

-  ANSI/VITA  1  VME64  Specification,  1994. 

-  ANSI/VITA  1 .1 ,  VME64  Extensions,  1997. 

WS.MS.5. 1.2.2  I/O  Buses 

I/O  buses  can  be  lengthy,  can  have  many  types  of  devices  connected  to  them,  and  often  have  a  wide 
range  in  the  data  bandwidth  of  devices  connected  to  them.  I/O  buses  do  not  typically  interface  directly 
to  the  memory  but  use  either  a  processor-memory  or  a  backplane  bus  to  connect  to  memory. 

WS.MS.5.1 .2.2(a)  Emerging.  The  following  standard  is  emerging  for  applications  that  require  an 
efficient  peer-to-peer  I/O  bus  capable  of  handling  up  to  16  devices,  including  one  or  more  hosts.  This 
standard  includes  command  sets  for  magnetic  and  optical  disks,  tapes,  printers,  processors,  CD-ROMS, 
scanners,  medium  changers,  and  communication  devices. 

-  ANSI  X3.131 ,  Information  Systems  -  Small  Computer  Systems  Interface  -  2  (SCSI-2),  1 994. 

The  following  industrial  bus  standard  is  emerging  for  applications  requiring  high-speed  data  transfer, 
rugged  construction,  excellent  shock  and  vibration  resistance,  Plug’n  Play  capability,  and  the  desire  for 
future  hot-swappable  support: 

-  PCI  Industrial  Computer  Manufacturer’s  Group  (PICMG):  Compact  PCI  Specification,  R2.1, 
September  1997. 
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WS.MS.5. 1.2.3  Single  Board  Computers  (SBCs)  Expansion  Buses 

The  SBC  expansion  bus  is  a  high-speed  I/O  bus  which  allows  microprocessors  to  communicate  with 
external  devices. 

WS.MS.5.1 .2.3(a)  Emerging.  The  PC  Card  standard  will  be  used  by  applications  requiring 
hot-swappable  peripherals  that  add  memory,  mass  storage,  and  I/O  capabilities  to  computers  in  a 
rugged,  compact  form  factor.  The  following  standard  is  emerging: 

-  Personal  Computer  Memory  Card  International  Association  (PCMCIA):  PC  Card  Standard, 
March  1997. 
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WS.MUS.1  Subdomain  Description 

Munition  Systems  included  in  this  subdomain  are  those  whose  parameters  cannot  be  accurately 
described  within  the  parameters  of  the  well-defined  Weapon  Systems  subdomains  of  Missile  Systems, 
Soldier  Systems,  Ground  Vehicle  Systems,  or  Aviation  Systems.  These  Munition  Systems  arc  primarily 
unattended  and  autonomous,  with  unique  environmental  and  operational  mission  requirements 
(e.g.,  positive  systems  control  and  management,  long-range  remote  communications,  physical 
packages  and  platforms,  security  and  survivability,  performance,  safety)  that  are  not  common  to  other 
subdomains.  Their  system  elements  may  include  combinations  of  autonomous  and  remotely 
commanded  munitions  with  or  without  the  following:  onboard  sensors,  networked  combat  sensors 
and/or  sensor  suites,  and  control  stations  with  integral  combat  communications,  including  combat 
communication  systems,  information  processing  gateways,  and  repeaters. 

Within  the  Department  of  Defense  (DoD)  inventory  of  weapon  systems,  many  systems  do  not  fit  within 
the  parameters  of  the  well-defined  Weapon  Systems  subdomains  of  Missile  Defense  Systems,  Soldier 
Systems,  Ground  Vehicle  Systems,  or  Aviation  Systems.  These  non-mobile,  transportable,  weapon 
systems  include,  but  are  not  limited  to,  munitions,  munitions  integrated  with  sensors,  control  stations, 
combat  communication  systems,  repeaters,  and  gateways.  The  Munition  Systems  Subdomain  includes 
any  system  or  subsystem  that  contains  an  explosive  warhead  (such  as  dumb,  smart,  and  precision 
bombs,  or  mines  and  artillery  shells)  and  that  detects,  classifies,  identifies,  intercepts,  and  destroys  or 
negates  the  effectiveness  of  the  enemy. 

WS.MUS.2  Purpose  and  Scope 

This  subdomain  builds  on  Weapon  Systems  Domain  by  identifying  Munition  Systems 
Subdomain-specific  standards  including  information  standards  and  analogous  standards  applicable  to 
Munition  Systems.  (See  1.7.3  for  relationships  between  Core,  domain,  and  subdomain  standards.)  The 
primary  purpose  of  establishing  a  subdomain  is  to  ensure  interoperability,  defined  as  the  ability  of  two 
or  more  systems  or  components  to  exchange  data  and  use  information  (IEEE  STD  610.12A-1990) 
within  the  family  of  systems  that  constitute  the  subdomain.  This  version  is  focused  solely  on  Landmine 
Munition  Systems,  with  the  intent  of  expanding  this  subdomain  in  the  future. 

The  scope  of  this  subdomain  is  the  entire  Munition  Systems  Subdomain  (as  defined  in  the  overview  and 
subdomain  description  above).  However,  the  standards  listed  within  this  version  of  the  subdomain 
solely  address  support  for  Landmine  Munition  Systems,  as  a  first  step  in  evolving  a  comprehensive  and 
complete  set  of  standards  for  Munition  Systems.  It  is  acknowledged  that  this  evolution  will  require 
interaction  with  many  communities  to  resolve  standardization  issues. 

WS.MUS.3  Background 

This  subdomain  was  developed  to  specify  the  unique  interoperability  standards  for  DoD  Munitions  and 
their  corresponding  systems. 

WS.MUS.4  Subdomain-Specific  Services  and  Interfaces 

The  Interfaces  View  of  the  Technical  Reference  Model  (TRM),  depicted  in  Figure  1-3,  provides 
sufficient  fidelity  for  identifying  classes  of  interfaces  to  apply  open  systems  interface  standards  to  the 
design  of  real-time  and  embedded-hardware/software  systems.  The  Interfaces  View  also  facilitates  the 
identification  of  critical  functions  and  interfaces  within  the  real-time  and  embedded-computing  systems 
of  the  Munition  Systems  Subdomain. 
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This  section  provides  a  common  framework  identifying  mandated  and  emerging  embedded-computing 
interface  standards  associated  with  the  logical  and  direct  interface  classes  defined  for  the  layers 
depicted  in  the  Interfaces  View  of  the  TRM.  Only  those  layers  of  the  TRM  that  have 
subdomain-specific  mandated  or  emerging  standards  identified  are  addressed  in  this  section. 

WS.MUS.4.1  Application  Software  Layer  Interfaces 

The  Application  Software  Layer  Interfaces  provide  a  set  of  resources  that  support  the  services  on  which 
application  software  will  execute.  It  provides  interfaces  to  services  that,  as  much  as  possible,  make  the 
implementation  specific  characteristics  of  the  platform  transparent  to  the  application  software. 

WS.MUS.4.1  (a)  Emerging.  The  Sensor  Link  Protocol  Message  Set  (SLP)  was  developed  for  use  as  a 
common  interface  between  electro-optical  sensor  systems  and  a  diverse  set  of  host  computer  systems. 
The  SLP  message  set  is  decoupled  from  lower  layer  protocols  to  allow  implementers  the  flexibility  to 
select  from  a  number  of  open  standards  such  as  RS-232/485,  FireWire  or  Universal  Serial  Bus  (USB). 
The  SLP  message  set  is  used  in  conjunction  with  the  SLP  Interface  Control  Document  to  develop  a 
common  digital  data  exchange  mechanism  between  sensors  and  host  computing  devices  that  offer  full 
remote  operation  and  control  of  those  sensors  by  a  host  computing  device  in  both  a  point-to-point  and 
networked  environment.  The  following  emerging  standard  defines  the  SLP  message  set: 

-  SLP-MSG-210,  Revision,  Sensor  Link  Protocol  Message  Set,  26  March  2001. 

WS.MUS.4.2  Physical  Resources  Layer  Interfaces 

Standards  that  conform  to  the  class  of  interfaces  specified  by  the  Physical  Resources  Layer  of  the  TRM 
interface  view  are  addressed  in  this  section.  This  section  identifies: 

□  The  interface  standards  that  provide  the  requirements  for  establishing  a  data  interchange 
interface  between  Physical  Resources  and  enable  bus  or  communications  link  boards  to  address 
their  peers  in  another  node  or  system,  and 

□  The  interface  standards  that  support  the  direct  connections  between  Physical  Resources,  such 
as  those  needed  to  enable  buses  and  communications  links  to  address  processors  or  those 
needed  to  enable  processors  to  address  memory  registers. 

WS.MUS.4.2. 1  Parallel  Buses 

A  Parallel  bus  transfers  information  (data,  interrupts,  arbitration,  timing,  etc.)  by  sending  a  number  of 
bits  (such  as  8  or  16)  at  the  same  time  using  multiconductor  cables  and  connectors. 

WS.MUS.4.2. 1.1  I/O  Buses 

I/O  buses  can  be  lengthy,  can  have  many  types  of  devices  connected  to  them,  and  often  have  a  wide 
range  in  the  data  bandwidth  of  devices  connected  to  them.  I/O  buses  do  not  typically  interface  directly 
to  the  memory  but  use  either  a  processor-memory  or  a  backplane  bus  to  connect  to  memory. 

WS.MUS.4.2. 1.1(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 

WS.MUS.4.2. 1.2  Single  Board  Computers  (SBCs)  Expansion  Buses 

The  SBC  expansion  is  high-speed  I/O  bus  which  allows  microprocessors  to  communicate  with  external 
devices. 

WS.MUS.4.2. 1 .2(a)  Emerging.  There  are  no  emerging  standards  in  this  area. 
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WS.SS.1  Subdomain  Description 

The  systems  of  this  subdomain  integrate  weapons,  target  detection,  location  and  warning  sensors, 
ballistic  and  environmental  protective  equipment,  positioning  and  location  equipment,  helmet-mounted 
displays,  load  carrying,  sustainment  and  special-purpose  equipment  onto  the  soldier  as  the  platform. 
The  systems  are  functionally  integrated  using  an  embedded  computer  with  multiple  pieces  of  radio 
communications  equipment  to  enhance  command-and-control  and  combat  effectiveness.  These 
capabilities  are  achieved  through  integration  of  government-furnished  equipment  (GFE)  and  the  use  of 
commercial  off-the-shelf  (COTS)  technologies  to  meet  the  key  performance  parameters  (KPPs)  of 
soldier  systems.  These  systems  are  optimized  to  minimize  the  total  weight  earned  by  the  individual 
while  minimizing  the  weight  canned  by  the  soldier  as  well  as  the  cognitive  overload.  These  systems  are 
required  to  meet  the  tactical  battlefield  environmental  characteristics  including  delivery  by  parachute 
while  worn  by  the  soldier.  All  systems  are  self-contained,  man-packed,  and  battery-powered.  Systems 
do  not  rely  on  any  fixed  infrastructure  to  meet  the  operational  performance  requirements. 

WS.SS.2  Purpose  and  Scope 

This  subdomain  builds  on  the  Weapon  Systems  Domain  by  identifying  Soldier  Systems 
Subdomain-specific  standards  including  information  standards  and  analogous  standards  applicable  to 
Soldier  Systems.  (See  1.7.3  for  relationships  between  JTA  Core,  domain,  and  subdomain  standards.) 

Systems  covered  within  the  Soldier  Systems  Subdomain  include  any  system  or  subsystem  integrating 
target  location,  target  identification,  target  acquisition,  enhanced  survivability,  navigation,  position 
location,  enhanced  mobility,  and  command-and-control  into  a  system  worn  or  earned  by  an  individual 
soldier  in  performance  of  assigned  duties. 

WS.SS.3  Background 

The  standards  in  this  subdomain  are  based  on  the  work  performed  by  the  weapons  community.  The 
following  documents  provide  useful  background  information  regarding  soldier  systems  with  particular 
emphasis  on  fighting  systems: 

□  The  Soldier  Integrated  Protective  Ensemble  (SIPE),  Army  Concept  Technology  Demonstration 
(ACTD),  U.S.  Army  Natick  Research,  Development  and  Engineering  Command, 

September  1991. 

□  The  Enhanced  Integrated  Soldier  System  (TEISS),  Army  Science  Board  Study, 

30  March  1993. 

□  The  Land  Warrior  Operational  Requirements  Document  (ORD),  HQ  U.S.  Army  Training  and 
Doctrine  Command,  1  October  2001. 

WS.SS.4  Subdomain-Specific  Services  and  Interfaces 

The  Interfaces  View  of  the  Technical  Reference  Model  (TRM),  depicted  in  Figure  1-3,  provides 
sufficient  fidelity  for  identifying  classes  of  interfaces  to  apply  open  systems  interface  standards  to  the 
design  of  real-time  and  embedded  hardware/software  systems.  The  Interface  View  also  facilitates  the 
identification  of  critical  functions  and  interfaces  within  the  real-time  and  embedded-computing  systems 
of  the  Soldier  Systems  Subdomain. 

This  section  provides  a  common  framework  identifying  mandated  and  emerging  embedded-computing 
interface  standards  associated  with  the  logical  and  direct  interface  classes  defined  for  the  layers 
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depicted  in  the  Interfaces  View  of  TRM.  Only  those  layers  of  the  TRM  that  have  subdomain-specific 
mandated  or  emerging  standards  identified  are  addressed  in  this  section. 

WS.SS.4.1  Application  Software  Layer  Interfaces 

The  Application  Software  Layer  Interfaces  provide  a  set  of  resources  that  support  the  services  on  which 
application  software  will  execute.  It  provides  interfaces  to  services  that,  as  much  as  possible,  make  the 
implementation  specific  characteristics  of  the  platform  transparent  to  the  application  software. 

WS.SS.4.1  (a)  Emerging.  The  Sensor  Link  Protocol  Message  Set  (SLP)  was  developed  for  use  as  a 
common  interface  between  electro-optical  sensor  systems  and  a  diverse  set  of  host  computer  systems. 
The  SLP  message  set  is  decoupled  from  lower  layer  protocols  to  allow  implementers  the  flexibility  to 
select  from  a  number  of  open  standards  such  as  RS-232/485,  FireWire  or  USB.  The  SLP  message  set  is 
used  in  conjunction  with  the  SLP  Interface  Control  Document  to  develop  a  common  digital  data 
exchange  mechanism  between  sensors  and  host  computing  devices  that  offer  full  remote  operation  and 
control  of  those  sensors  by  a  host  computing  device  in  both  a  point-to-point  and  networked 
environment.  The  following  emerging  standard  defines  the  SLP  message  set: 

-  SLP-MSG-210,  Revision,  Sensor  Link  Protocol  Message  Set,  26  March  2001. 

WS.SS.4.2  Physical  Resources  Layer  Interfaces 

Standards  that  conform  to  the  class  of  interfaces  specified  by  the  Physical  Resources  Layer  of  the  TRM 
interface  view  are  addressed  in  this  section.  This  section  identifies: 

□  The  interface  standards  that  provide  the  requirements  for  establishing  a  data  interchange 
interface  between  Physical  Resources  and  enable  bus  or  communications  link  boards  to  address 
their  peers  in  another  node  or  system,  and 

□  The  interface  standards  that  support  the  direct  connections  between  Physical  Resources,  such 
as  those  needed  to  enable  buses  and  communications  links  to  address  processors  or  needed  to 
enable  processors  to  address  memory  registers. 

WS.SS.4.2. 1  Serial  Buses 

Serial  Buses  are  buses  that  transmit  information  one  bit  at  a  time  in  a  sequential  or  serial  manner. 

WS.SS.4.2. 1(a)  Emerging.  The  IEEE  1394b-2001  is  a  full  use  standard  whose  scope  is  to  provide  a 
supplement  to  IEEE  1394-1995  and  IEEE  1394-2000  that  defines  features  and  mechanisms  conducive 
to  gigabit  speeds  in  a  backward  compatible  fashion  and  the  ability  to  signal  over  single  hop  distances 
of  up  to  100m.  The  following  standard  is  emerging: 

-  IEEE  1394b-2001 ,  IEEE  Standard  for  a  High  Performance  Serial  Bus,  2001 . 

The  Digital  Visual  Interface  (DVI)  is  a  display  technology  independent  interface  standard  between  a 
host  and  a  display.  DVI  provides  a  plug-and-play  capability  in  a  single  connector  supporting  both 
analog  and  digital  or  digital  only.  This  standard  is  sponsored  by  the  Digital  Display  Working  Group 
(DDWG)  comprised  of  Intel  Corp.,  Silicon  Image,  Compaq  Computer,  Fujitsu.  HR  IBM  and  NEC,  and 
is  considered  an  open  standard.  The  following  standard  is  emerging: 

-  Digital  Visual  Interface  (DVI),  Digital  Display  Working  Group  (DDWG),  Revision  1 .0, 

02  April  1999. 
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Low  Voltage  Differential  Signaling  (LVDS)  is  denoted  by  the  EIA/TIA-644  standard,  which  is  a 
balanced  (differential)  bus  wherein  only  the  electrical  layer  (RCVR/TX)  is  defined.  LVDS  is  an 
approach  to  achieve  high  bandwidth  with  low  EMI,  which  is  applicable  to  a  myriad  of  commonly  used 
media,  and  is  also  pin-to-pin  compatible  with  RS-422  transmitters  and  receivers.  LVDS  is  an  approved 
standard  through  ANSI  forum.  This  standard  is  used  for  high-bandwidth,  low-power,  digital  serial 
interface,  used  in  displays  and  cameras.  The  following  standard  is  emerging 

-  Electrical  Characteristics  of  LVDS  Interface  Circuits,  March  1996. 
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Note:  Multiple  acronyms  are  sometimes  shown  for  the  same  term  where  the  different  acronyms  arc 
used  in  the  document.  For  example,  the  text  of  the  document  consistently  uses  “Mbits/s”  for  “Megabits 
per  second,”  but  the  abbreviation  “Mbps”  is  used  in  the  titles  of  some  standards. 


AAL 

ABBET 

ABOR 

ACC 

ACP 

ACR 

ADC 

ACTD 

ADE 

ADS 

ADS-A 

ADS-B 

ADT 

AEP 

AES 

AES3 

AFP 

AH 

AI-ESTATE 

AIM 

AIS 

AITI 

ALE 

ALSP 

AMB 

AMSS 

ANSI 

AOR 

API 

AR 

ARC 

ARI 

ARTS 

ASD 


ATM  Adaptation  Layer 
A  Broad-Based  Environment  for  Test 
Abort 

Architecture  Coordination  Council 

Allied  Communications  Publication 

American  College  of  Radiology 

Automatic  Data  Capture 

Advanced  Concept  Technology  Demonstration 

Application  Development  Environment 

Automatic  Dependent  Surveillance 

Automatic  Dependent  Surveillance  -  Address 

Automatic  Dependent  Surveillance  -  Broadcast 

Air  Data  Terminal 

Application  Environment  Profile 

Application  Environment  Specification 

Audio  Engineering  Society  3 

Adapter  Function  and  Parametric  Data  Interface 

Authentication  Header 

Artificial  Intelligence-Exchange  and  Services  Tie  to  All  Test  Environments 

Advanced  Information  Management 

Automated  Information  System 

Automated  Interchange  of  Technical  Information 

Automated  Link  Establishment 

Aggregate-Level  Simulation  Protocol 

ATS  Management  Board 

Aeronautical  Mobile  Satellite  Services 

American  National  Standards  Institute 

Area  of  Responsibility 

Application  Program  Interface 

Airborne  Reconnaissance 

Equal  Arc  Second  Raster  Chart/Map 

Automatic  Test  Systems  (ATS)  Research  and  Development  (R&D)  Integrated  Product 
Team  (IPT) 

Automated  Radar  Terminal  System 
Assistant  Secretary  of  Defense 
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ASD(C3l)/DoD  CIO 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
lntelligence)/DoD  Chief  Information  Officer 

ASICs 

Application-Specific  Integrated  Circuits 

ASR 

Airport  Surveillance  Radar 

ATA 

Army  Technical  Architecture 

ATCRBS 

Air  Traffic  Control  Radar  Beacon  System 

ATE 

Automated  Test  Equipment 

ATM 

Asynchronous  Transfer  Mode;  Air  Traffic  Management 

ATN 

Aeronautical  Telecommunications  Network 

ATS 

Automatic  Test  Systems 

AV 

Air  Vehicle;  Aviation 

AVSDWG 

Aviation  Subdomain  Working  Group 

BER 

Bit  Error  Rate 

BGP 

Border  Gateway  Protocol 

BIIF 

Basic  Image  Interchange  Format 

BioAPI 

Biometric  API 

bits/s 

Bits  per  second 

B-ISDN 

Broadband-Integrated  Services  Digital  Network 

BLoS 

Below  Line-of-Sight 

BMC3 

Ballistic  Missile  Command,  Control,  and  Communications 

BMD 

Ballistic  Missile  Defense 

BOOTP 

Bootstrap  Protocol 

bps 

Bits  Per  Second 

BRI 

Basic  Rate  Interface 

BUFR 

Binary  Universal  Format  for  Representation 

C2 

Command  and  Control 

C2CDM 

Command  and  Control  Core  Data  Model 

C3 

Consultation,  Command  and  Control 

C3I 

Command,  Control,  Communications,  and  Intelligence 

C4I 

Command,  Control,  Communications,  Computers,  and  Intelligence 

C4ISR 

Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and 
Reconnaissance 

CA 

Certification  Authority 

CAC 

Computer  Asset  Controller 

CAD 

Computer-Aided  Design 

CADRG 

Compressed  ARC  Digitized  Raster  Graphics 

CAE 

Common  Application  Environment 

CAF 

C4I  Architecture  Framework 

CALS 

Continuous  Acquisition  and  Life-Cycle  Support 
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CAM 

CASI 

CBC 

CBEFF 

CBR 

CBS 

CC 

CCB 

CCDF 

CCDM 

CCEB 

CCIB 

CCITT 

CCSDS 

CDE 

CDL 

CDMA 

CDRL 

CD-ROM 

CE 

CEN 

CFS 

CGI 

CGM 

CGMTI 

CHAP 

CHBDL-ST 

Cl 

CIB 

CIM 

CIPSO 

CJCS 

CJCSI 

CLI 

CM 

CMC 

CMI 

CMIP 

CMIS 

CMMS 


Computer-Aided  Manufacturing 
Common  ATM  Satellite  Interface 
Cipher  Block  Chaining 
Common  Biometric  Exchange  File  Format 
Constant  Bit  Rate 
Commission  for  Basic  Systems 

The  Common  Criteria  for  Information  Technology  Security  Evaluation 

Change  Control  Board 

Common  Cryptologic  Data  Format 

Common  Cryptologic  Data  Model 

Combined  Communications-Electronics  Board 

Common  Criteria  Implementation  Board 

International  Telegraph  &  Telephone  Consultative  Committee  (now  ITU-T) 

Consultative  Committee  for  Space  Data  Systems 

Common  Desktop  Environment 

Common  Data  Link 

Code  Division  Multiple  Access 

Contract  Data  Requirements  List 

Compact  Disk-Read  Only  Memory 

Controlled  Extensions 

European  Committee  for  Standardization 

Center  for  Standards 

Computer  Graphics  Interface 

Computer  Graphics  Metafile 

Common  Ground  Moving  Target  Indicator 

Challenge  Handshake  Authentication  Protocol 

Common  High  Bandwidth  Data  Link  Surface  Terminal 

Critical  Interface 

Controlled  Image  Base 

Common  Information  Model 

Common  Internet  Protocol  Security  Options 

Chairman  of  the  Joint  Chiefs  of  Staff 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 

Call-Level  Interface 

Configuration  Management 

Certificate  Management  Messages  over  Cryptographic  Message  Syntax 

Computer  Managed  Instruction 

Common  Management  Information  Protocol 

Common  Management  Information  Services 

Conceptual  Models  of  the  Mission  Space 
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CMS 

Cryptographic  Message  Syntax 

CNR 

Combat  Net  Radio 

CNS 

Communications  Navigation,  and  Surveillance 

COE 

Common  Operating  Environment 

COEA 

Cost  and  Operational  Effectiveness  Analysis 

COM 

Common  Object  Model;  Component  Object  Model 

CORBA 

Common  Object  Request  Broker  Architecture 

COTS 

Commercial  Off-the-Shelf 

CRD 

Capstone  Requirements  Document 

CRLs 

Certificate  Revocation  Lists 

CRY 

Cryptologic 

CS 

Combat  Support 

CSMA/CD 

Carrier  Sense  Multiple  Access  with  Collision  Detection 

CSP 

Common  Security  Protocol 

CSR 

Command  and  Status  Register 

CTRS 

Conventional  Terrestrial  Reference  System 

CXE 

Computer  to  External  Environments  Interface 

DAA 

Designated  Approving  Authority 

DAMA 

Demand  Assigned  Multiple  Access 

DAP 

Directory  Access  Protocol 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DAT 

Digital  Audio  Tape 

DBMS 

Database  Management  System 

DCE 

Distributed  Computing  Environment 

DCI 

Director,  Central  Intelligence 

DCOM 

Distributed  Component  Object  Model 

DDA 

DoD  Data  Architecture 

DDDS 

Defense  Data  Dictionary  System 

DDM 

DoD  Data  Model 

DDNS 

Dynamic  Domain  Name  System 

DDRS 

Defense  Data  Repository  System 

DED 

Data  Element  Definitions 

DEER  WG 

Data  Element  and  Exchange  Rule  Working  Group 

DES 

Data  Encryption  Standard 

3DESE 

Triple-DES  Encryption 

DHCP 

Dynamic  Host  Configuration  Protocol 

DIA 

Defense  Intelligence  Agency 

DICOM 

Digital  Imaging  and  Communication  In  Medicine 

DIF 

Data  Interchange  Format 
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DIGEST 

Dll 

DIRNSA 

DIS 

DISA 

DISN 

DISSG 

DITSCAP 

DLA 

DLWG 

DMS 

DMSO 

DMTD 

DMTF 

DNC 

DNS 

DoD 

DoDD 

DoDIIS 

DoDISS 

DoDSSP 

DOI 

DPPDB 

DRV 

DSA 

DSIC 

DSN 

DSP 

DSS 

DSS1 

DSSS 

DSSSL 

DTD 

DTF 

DTIF 

DTOP 

DTS 

EAM 

EAO 


Digital  Geographic  Information  Exchange  Standard 
Defense  Information  Infrastructure 
Director,  NSA 

Distributed  Interactive  Simulation;  Draft  International  Standard 

Defense  Information  Systems  Agency  (formerly  Defense  Communications  Agency  [DCA]) 

Defense  Information  System  Network 

Data  Interoperability  and  Standardization  Steering  Group 

DoD  IT  Security  Certification  &  Accreditation  Process 

Defense  Logistics  Agency 

Data  Link  Working  Group 

Defense  Message  System 

Defense  Modeling  and  Simulation  Office 

Digital  Message  Transfer  Device 

Distributed  Management  Task  Force 

Digital  Nautical  Chart 

Domain  Name  System 

Department  of  Defense 

DoD  Directive 

DoD  Intelligence  Information  Systems 

DoD  Index  of  Specifications  and  Standards 

DoD  Single  Stock  Point 

Domain  of  Interpretation 

Digital  Point  Positioning  Data  Base 

Instrument  Driver  Application  Programming  Interface 

Digital  Signature  Algorithm 

Defense  Standards  Improvement  Council 

Defense  Switched  Network 

Defense  Standardization  Program 

Digital  Signature  Standard 

Digital  Subscriber  Signaling  System  No  1 

Direct  Sequence  Spread  Spectrum 

Document  Style  and  Semantics  Specification  Language 

Document  Type  Definition 

Digital  Test  Data  Format 

Digital  Test  Interchange  Format 

Digital  Topographic  Data 

Defense  Transportation  System 

Emergency  Action  Message 
Executive  Agent  Office 
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EAP 

Emergency  Action  Procedure 

EB 

Electronic  Business 

EC 

Electronic  Commerce 

ECAPMO 

Electronic  Commerce  Acquisition  Program  Management  Office 

ECN 

Explicit  Congestion  Notification 

EDI 

Electronic  Data  Interchange 

EDIF 

Electronic  Data  Interchange  Format 

EDISMC 

EDI  Standards  Management  Committee 

EEI 

External  Environment  Interface 

EHF 

Extremely  High  Frequency;  Extra  High  Frequency 

EIA 

Electronics  Industries  Alliance 

E-MAIL 

Electronic  Mail 

EMI 

Electro-Magnetic  Interference 

ESP 

Encapsulating  Security  Payload 

EXCIMS 

Executive  Council  for  Modeling  and  Simulation 

FDMA 

Frequency  Division  Multiple  Access 

FED-STD 

Federal  Telecommunication  Standard 

FESMCC 

Federal  EDI  Standards  Management  Coordinating  Committee 

FIPS 

Federal  Information  Processing  Standards 

FOM 

Federation  Object  Model 

FP 

File-Handling  Protocol 

FPLMTS 

Future  Public  Land  Mobile  Telecommunications  Systems 

FPS 

Frames  Per  Second 

FRM 

Framework  Interface;  Functional  Requirements  Model  Functional  Reference  Model 

FTP 

File  Transfer  Protocol 

FTR 

Federal  Telecommunications  Recommendation 

FWG 

Functional  Working  Group 

GBAS 

Ground-Based  Augmentation  System 

GeoSym 

Geospatial  Symbols  for  Digital  Displays 

GFE 

Government  Furnished  Equipment 

GIC 

Generic  Instrument  Class  Interface 

GIF 

Graphics  Interchange  Format 

GIS 

Geographic  Information  System 

GNSS 

Global  Navigation  Satellite  System 

GOA 

Generic  Open  Architecture 

GOTS 

Government  off-the-shelf 

GPS 

Global  Positioning  System 

GRIB 

Gridded  Binary 
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GSM 
GSS 
GUI 
G  V 

HAIPE 

HCI 

HDBK 

HF 

HFDL 

HIDAR 

HI  PA  A 

HL7 

HLA 

HMAC 

HST 

HTML 

HTTP 

Hz 

I/O 

IAB 

IATF 

IBS 

1C 

ICAO 

ICB 

ICD 

ICL 

ICM 

ICMP 

ICP 

IDEFO 

IDEF1X 

IDL 

IDL  API 

IDUP 

IEC 

IEEE 

IER 


Global  System  for  Mobile  Communications 
Generic  Security  Service 
Graphical  User  Interface 
Ground  Vehicle 

High-Assurance  Internet  Protocol  Encryptor 

Human-Computer  Interface 

Handbook 

High-Frequency 

High-Frequency  Data  Link 

High  Data  Rate 

Health  Insurance  Portability  and  Accountability  Act 

Health  Level  7 

High-Level  Architecture 

keyed-Hashing  for  Message  Authentication 

Host  Computer  Interface 

Hypertext  Markup  Language 

Hypertext  Transfer  Protocol 

Hertz 

Input/Output 

Internet  Architecture  Board 

Information  Assurance  Technical  Framework 

Integrated  Broadcast  Service 

Intelligence  Community 

International  Civil  Aviation  Organization 

Instrument  Communication  Bus  Interface 

Interface  Control  Document 

Instrument  Command  Language  Interface 

Instrument  Communications  Manager  Interface 

Internet  Control  Message  Protocol 

Interface  Change  Proposal 

Integrated  Definition  for  Function  Modeling 

Integrated  Definition  for  Information  Modeling 

Interface  Definition  Language 

Interface  Definition  Language  Application  Program  Interface 
Independent  Data  Unit  Protection 
International  Electrotechnical  Commission 
Institute  of  Electrical  and  Electronics  Engineers 
Information  Exchange  Requirement 
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IETF 

l/EW 

IF 

IFF 

IFP 

IGES 

IGMP 

mop 

ILMI 

IMA 

IMINT 

IMT 

IOSA 

IKE 

IP 

IPC 

IPCP 

IPsec 

IPT 

IPv4 

IPv6 

IR 

IRIG 

IRV 

IS 

ISA 

ISAKMP 

ISB 

ISDN 

ISO 

ISO/IEC 

ISR 

ISS 

IT 

ITMRA 

ITOT 

ITSEC 

ITSG 

ITU 

ITU-T 


Internet  Engineering  Task  Force 

Intelligence  and  Electronic  Warfare 

Intermediate  Frequency 

Identification  of  Friends  and  Foes 

Instrument  Function  and  Parametric  Data  Interface 

Initial  Graphics  Exchange  Specification 

Internet  Group  Management  Protocol 

Internet  Inter-ORB  Protocol 

Interim  Local  Management  Interface 

Inverse  Multiplexing  for  ATM 

Imagery  Intelligence 

International  Mobile  Telecommunications 
Integrated  Overhead  SIGINT  Architecture 
Internet  Key  Exchange 
Internet  Protocol 

Institute  for  Interconnecting  and  Packaging  Electronic  Circuits 

Internet  Protocol  Control  Protocol 

Internet  Protocol  Security 

Integrated  Product  Team 

Internet  Protocol  Version  4 

Internet  Protocol  Next  Generation  Version  6 

Infrared 

Inter-Range  Instrumentation  Group 
International  Reference  Version 
Information  System 
Industry  Standard  Architecture 

Internet  Security  Association  and  Key  Management  Protocol 
Intelligence  Systems  Board 
Integrated  Services  Digital  Network 
International  Organization  for  Standardization 

International  Organization  for  Standardization,  International  Electrotechnical  Commission 
Intelligence,  Surveillance,  &  Reconnaissance 
Intelligence  Systems  Secretariat 
Information  Technology 

Information  Technology  Management  Reform  Act  (of  1996) 

ISO  Transport  Service  on  Top  of  TCP 

European  Information  Technology  Security  Evaluation  Criteria 
Information  Technology  Standards  Guidance 
International  Telecommunication  Union 

International  Telecommunication  Union  -  Telecommunications  Standardization  Sector 
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ITW/AA 

Integrated  Tactical  Warning  and  Attack  Assessment 

JASA 

Joint  Airborne  SIGINT  Architecture 

JDBC 

JAVA  Database  Connectivity 

JFIF 

JPEG  File  Interchange  Format 

JIEO 

Joint  Information  Engineering  Organization 

JIRA 

Japanese  Industry  Association  for  Radiation  Apparatus 

JPEG 

Joint  Photographic  Experts  Group 

JRE 

Joint  Range  Extension 

JREAP 

JRE  Application  Protocol 

JSA 

Joint  Systems  Architecture 

JTA 

Joint  Technical  Architecture 

JTADG 

Joint  Technical  Architecture  Development  Group 

JTAMDO 

Joint  Theater  Air  and  Missile  Defense  Organizations 

JTAWG 

Joint  Technical  Architecture  Working  Group 

JTDLMP 

Joint  Tactical  Data  Link  Management  Plan 

JTIDS 

Joint  Tactical  Information  Distribution  System 

JTF 

Joint  Task  Forces 

JV  2010 

Joint  Vision  2010 

JVM 

Java  Virtual  Machine 

Kbits/s 

Kilobits  per  second 

KEA 

Key  Exchange  Algorithm 

kHz 

Kilohertz 

KMP 

Key  Management  Protocol 

KPP 

Key  Performance  Parameters 

LAAS 

Local  Area  Augmentation  System 

LAN 

Local  Area  Network 

LANE 

Local  Area  Network  Emulation 

LCP 

Link  Control  Protocol 

LCSCES 

Low  Speed  Circuit  Emulation  Service 

LDAP 

Lightweight  Directory  Access  Protocol 

LDAPv3 

Lightweight  Directory  Access  Protocol  3 

LDR 

Low  Data  Rate 

LF 

Low  Frequency 

LMES 

List  of  Mandated  and  Emerging  Standards 

LOM 

Learning  Object  Metadata 

LOS 

Line-of-Sight 

LPI 

Low  Probability  of  Intercept 
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LQM 

Link  Quality  Monitoring 

LRAs 

Local  Registration  Authorities 

LSRTAP 

Logic  Automated  Stimulus  and  Response  (LASAR)  Teradyne  ASCII  Post-processor  (TAP) 

LSB 

Linux  Standard  Board 

LUNI 

LANE  User-Network  Interface 

M&S 

Modeling  and  Simulation 

MAC 

Medium-Access  Control 

MAIS 

Major  Automated  Information  System 

MAN 

Metropolitan  Area  Network 

MASINT 

Measurement  and  Signature  Intelligence 

MASPS 

Minimum  Aviation  Systems  Performance  Standards 

MAU 

Medium-Access  Unit 

Mbits/s 

Megabits  per  second 

Mbps 

Megabits  per  second 

MC&G 

Mapping,  Charting,  and  Geodesy 

MCU 

Multipoint  Control  Units 

MD 

Missile  Defense 

MDA 

Missile  Defense  Agency 

MDAPS 

Major  Defense  Acquisition  Programs 

MDR 

Medium  Data  Rate 

MED 

Medical 

MEECN 

Minimum  Essential  Emergency  Communications  Network 

MELP 

Mixed  Excitation  Linear  Prediction 

MG 

Multinational  Group 

MHP 

Mobile  Host  Protocol 

MHS 

Military  Health  System 

MHSS 

Military  Health  Services  System 

MHz 

Megahertz 

Ml 

Motion  Imagery 

MIB 

Management  Information  Base 

MIDS 

Multi-functional  Information  Distribution  System 

MIL-HDBK 

Military  Handbook 

MILSATCOM 

Military  Satellite  Communications 

MIL-STD 

Military  Standard 

MIME 

Multipurpose  Internet  Mail  Extensions 

MISB 

Motion  Imagery  Standards  Board 

MISP 

Motion  Imagery  Standards  Profile 

MISSI 

Multilevel  Information  Systems  Security  Initiative 

MIST 

Miniature  Interoperable  Surface  Terminal 
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MLPP 

Multi-Level  Precedence  and  Preemption 

MMF 

Multimedia  Formats  Interface 

MMPM 

MEECN  Message-Processing  Mode 

MNG 

Multiple-Image  Network  Graphics 

MOF 

Meta-Object  Facility 

MPEG 

Motion  Pictures  Expert  Group 

MPLS 

Multiprotocol  Label  Switching 

MPOA 

Multiprotocol  over  ATM 

MS 

Missile  Systems 

MSMP 

Modeling  and  Simulation  Master  Plan 

MSI 

Multispectral  Imagery 

MSP 

Message  Security  Protocol 

MTA 

Message  Transfer  Agent 

MTI 

Moving  Target  Indicator 

MUS 

Munition  Systems 

MXF 

Material  Exchange  Format 

NAFAG 

NATO  Air  Force  Armaments  Group 

NAS 

National  Airspace  System 

NASA 

National  Aeronautics  and  Space  Administration 

NATO 

North  Atlantic  Treaty  Organization 

NAVWAR 

Navigation  Warfare 

NAWCADLKE 

Naval  Air  Warfare  Center  Aircraft  Division-Lakehurst 

NBC 

Nuclear,  Biological,  Chemical 

NCC 

Nuclear  Command  and  Control 

NCPDP 

National  Council  for  Prescription  Drug  Program 

NCSC 

National  Computer  Security  Center 

NEMA 

National  Electrical  Manufacturers  Association 

NET 

Network  Protocols  Interface 

NIMA 

National  Imagery  and  Mapping  Agency 

NIST 

National  Institute  of  Standards  and  Technology 

NITF 

National  Imagery  Transmission  Format 

NITFS 

National  Imagery  Transmission  Format  Standard 

NMD 

National  Missile  Defense 

NP 

Network  Protocol 

NRO 

National  Reconnaissance  Office 

NSA 

National  Security  Agency 

NSGI 

National  System  for  Geospatial  Intelligence 

NSIF 

NATO  Secondary  Imagery  Format 

NSM 

Network  and  Systems  Management 
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NSS 

NTIS 

NTISSP 

NTM 

NTP 

NTSC 

NTSDS 

OA 

ODBC 

ODMG 

OE 

OJCS 

OLE 

OMA 

OMG 

OMT 

OOTW 

ORD 

OS 

OSD 

OSE 

OUSD(AT&L) 

OSF 

OSI 

OSJTF 

OSPF 

PASV 

PBBE 

PCE 

PCI 

PCIMG 

PCMCIA 

PCS 

PESO 

PHY 

PICS 

PIDP 

PKI 
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National  Security  Systems 
National  Technical  Information  Service 

National  Telecommunications  and  Information  Systems  Security  Policy 

National  Technical  Means 

Network  Time  Protocol 

National  Television  Standards  Committee 

National  Target/Threat  Signature  Data  System 

Operational  Architecture 
Open  Database  Connectivity 
Object  Data  Management  Group 
Operating  Environment 
Office  of  the  Joint  Chiefs  of  Staff 
Object  Linking  and  Embedding 
Object  Management  Architecture 
Object  Management  Group 
Object  Model  Template 
Operations  Other  Than  War 
Operational  Requirements  Document 
Operating  System 
Office  of  the  Secretary  of  Defense 
Open  Systems  Environment 

Office  of  the  Under  Secretary  of  Defense  (Acquisition,  Technology,  and  Logistics) 

Open  Software  Foundation 

Open  Systems  Interconnection 

Open  Systems  Joint  Task  Force 

Open  Shortest  Path  First 

Passive 

Performance  Based  Business  Environment 

Platform  Communications  Element 

Peripheral  Computer  Interface 

PCI  Industrial  Computer  Manufacturer’s  Group 

Personal  Computer  Memory  Card  International  Association 

Personal  Communications  Services 

Perceptual  Evaluation  of  Speech  Quality 

Physical  Layer 

Protocol  Implementation  Conformance  Statement 
Programmable  Interface  Data  Processor 
Public-Key  Infrastructure 
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PLDs 

PMNV/RSTA 

PNG 

PNNI 

POSIX 

PP 

PPP 

PPS 

PRI 

PRO 

PSK 

PSTN 

QoS 

R&D 

RAs 

RADIUS 

RCC 

RCS 

RDA 

RDBMS 

RDF 

RF 

RFC 

RFI 

RFP 

RFX 

RMA 

RMON 

RNP 

ROHC 

RPF 

RR 

RSVP 

RTCA 

RTI 

RTP 

RTS 

RTT 


Programmable  Logic  Devices 

Program  Management  Office  for  Night  Vision/Reconnaissance  and  Target  Acquisition 
Portable  Network  Graphics 
Private  Network-Network  Interface 

Portable  Operating  System  Interface  for  Computer  Environments 

Protection  Profile 

Point-to-Point  Protocol 

Precise  Positioning  Service 

Primary  Rate  Interface 

Product  Data  Association 

Phase  Shift  Keying 

Public  Switched  Telephone  Networks 

Quality  of  Service 

Research  and  Development 

Registration  Authorities 

Remote  Authentication  Dial  In  User  Service 

Range  Commanders  Council 

Records  Control  Schedule 

Remote  Database  Access 

Relational  Database  Management  System 

Resource  Description  Framework 

Radio  Frequency 

Request  for  Comments 

Receiver  Fixture  Interface  Alliance 

Request  for  Proposals 

Receiver/Fixture  Interface 

Records  Management  Application 

Remote  Monitoring 

Required  Navigation  Performance 

Robust  Header  Compression 

Raster  Product  Format 

Resource  Records 

Resource  Reservation  Protocol 

Radio  Technical  Commission  for  Aeronautics 

Runtime  Infrastructure 

Real-Time  Protocol 

Runtime  Services  Interface 

Radio  Transmission  Technologies 
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SA 

SAASM 

SAE 

SARPS 

SAR  SDE 

SATCOM 

SBAS 

SBU 

SCC 

SCE 

SCPS 

SCSI-2 

SDE 

SDF 

SDK 

SDN 

SDNS 

SDT 

SEDRIS 

SEIWG 

SFP 

SGML 

SHF 

SIF 

SIGINT 

SILS 

SIP 

SIPE 

SIPRNET 

SIS 

SIU 

SLP 

S/MIME 

SMPTE 

SMTP 

SNMP 

SOAP 

SOM 

SONET 


Systems  Architecture 

Selective  Availability  Anti-Spoofing  Module 

Society  of  Automotive  Engineers 

Standards  and  Recommended  Practices 

Synthetic  Aperture  Radar  Support  Data  Extension 

Satellite  Communications 

Space-Based  Augmentation  System 

Sensitive  but  unclassified 

Standards  Coordinating  Committee 

Surface  Communications  Element 

Space  Communications  Protocol  Standards 

Small  Computer  Systems  Interface-2 

Support  Data  Extensions 

Simulation  Data  Format 

Software  Development  Kit 

Secure  Data  Network 

Secure  Data  Network  System 

Surveillance  Data  Translator 

Synthetic  Environment  Data  Representation  and  Interchange  Specification 

Security  Equipment  Integration  Working  Group 

Switch  Function  and  Parametric  Data  Interface 

Standard  Generalized  Markup  Language 

Super  High  Frequency 

Standard  Simulator  Database  Interchange  Format 
Signals  Intelligence 

Standard  for  Interoperable  LAN  Security 

Session  Initiation  Protocol 

Soldier  Integrated  Protective  Ensemble 

Secure  Internet  Protocol  Router  Network 

Signal-in-Space 

System  Interface  Unit 

Sensor  Link  Protocol 

Secure/Multipurpose  Internet  Mail  Extensions 

Society  of  Motion  Picture  and  Television  Engineers 

Simple  Mail  Transfer  Protocol 

Simple  Network  Management  Protocol 

Simple  Object  Access  Protocol 

Simulation  Object  Model 

Synchronous  Optical  Network 
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soo 

Statement  Of  Objective 

sow 

Statement  of  Work 

SP 

Security  Protocol 

SPDs 

Special-Purpose  Devices 

SPIA 

Standards  Profile  for  Imagery  Access 

SPS 

Standard  Positioning  Service 

SQL 

Structured  Query  Language 

SR 

Bellcore  Special  Report 

SR 

Space  Reconnaissance 

SRM 

Spatial  Reference  Model 

SRS 

Software  Requirement  Specification 

SS 

Soldier  Systems 

SSDB 

Standard  Simulator  Data  Base 

SSH 

Secure  Shell 

SSL 

Secure  Socket  Layer 

ST 

Security  Target 

STANAG 

Standardization  Agreement  [NATO] 

STARS 

Standard  Terminal  Automation  Replacement  System 

STD 

Standard 

STEP 

Standard  for  the  Exchange  of  Product  Model  Data 

STOU 

Store  Unique 

SUS 

Single  UNIX  Specification 

SWM 

Switch  Matrix  Interface 

TA 

Technical  Architecture 

TAC02 

Tactical  Communications  Protocol  2 

TADIL 

Tactical  Digital  Information  Link 

TAFIM 

Technical  Architecture  Framework  for  Information  Management 

TASG 

Technical  Architecture  Steering  Group 

TC 

Technical  Committee 

TCAP 

Transaction  Capabilities  Application  Part 

TCAS 

Traffic  Alert  and  Collision  Avoidance  System 

TCDL 

Tactical  Common  Data  Link 

TCP 

Transmission  Control  Protocol 

TCSEC 

Trusted  Computer  Security  Evaluation  Criteria 

TDD 

Time  Division  Duplex 

TDL 

Tactical  Data  Link 

TDMA 

Time  Division  Multiple  Access 

TED 

TriTeal  Enterprise  Desktop 

TEISS 

The  Enhanced  Integrated  Soldier  System 
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TELNET 

TFTP 

TGWG 

TIA 

TIDP 

TIDP-TE 

TIS 

TIS 

TLS 

TMD 

TMN 

TOG 

TOS 

TP 

TPO 

TPD 

TPS 

TR 

TRIM 

TRM 

TRSL 

TSIG 

TSIX(RE) 

TSR 

TUAV 

TV 


Telecommunications  Network 

Trivial  File  Transfer  Protocol 

Time  and  Geospatial  Working  Group 

Telecommunications  Industry  Association 

Technical  Interface  Design  Plan 

Technical  Interface  Design  Plan  (Test  Edition) 

Technical  Interface  Specification 
Traffic  Information  Service 
Transport  Layer  Security 
Theater  Missile  Defense 
Telecommunications  Management  Network 
The  Open  Group 

Type-of-Service;  Test  Program  to  Operating  System  Interface  (ATS  Subdomain) 

Transport  Protocol 

Transport  Protocol  Class  0 

Test  Program  Documentation  Interface 

Test  Program  Set 

Technical  Report 

Test  Resource  Information  Model 

Technical  Reference  Model 

Test  Requirements  Specification  Language 

Trusted  Systems  Interoperability  Group 

Trusted  Security  Information  Exchange  for  Restricted  Environments 

Test  Strategy  Report 

Tactical  Unmanned  Air  Vehicle 

Technical  View 


u 

UCA 

UCA-TA 

UCS 

UDP 

UHF 

UIS 

UML 

UMS 

UN 

UNI 

UPN 

URL 


Unclassified 

Unified  Cryptologic  Architecture 

UCA-Technical  Architecture 

Universal  Multiple-Octet  Coded  Character  Set 

User  Datagram  Protocol 

Ultra  High  Frequency 

User  Interface  Specification 

Unified  Modeling  Language 

Unattended  MASINT  Sensor 

United  Nations 

User-Network  Interface 

Universal  Product  Number 

Uniform  Resource  Locator 
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USA 

United  States  Army 

USACOM  TMD 

United  States  Atlantic  Command  Theater  Missile  Defense 

USAF 

United  States  Air  Force 

USCG 

United  States  Coast  Guard 

uses 

United  States  Cryptologic  System 

USD(A&T) 

Under  Secretary  of  Defense  (Acquisition  and  Technology) 

USD(AT&L) 

Under  Secretary  of  Defense  (Acquisition,  Technology,  and  Logistics) 

USIS 

United  States  Imagery  System 

USM 

User-based  Security  Model 

USMC 

United  States  Marine  Corps 

USMTF 

United  States  Message  Text  Format 

USN 

United  States  Navy 

USNO 

United  States  Naval  Observatory 

USSTRATCOM 

United  States  Strategic  Command 

UTC 

Coordinated  Universal  Time 

UTC  (USNO) 

UTC  as  maintained  at  the  U.S.  Naval  Observatory 

UTR 

UUT  Test  Requirements 

UUT 

Unit  Under  Test 

UVMap 

Urban  Vector  Smart  Map 

VACM 

View-based  Access  Control  Model 

VCEG 

Video  Coding  Expert  Group 

VHDL 

VHSIC  Hardware  Description  Language 

VHF 

Very  High  Frequency 

VHS 

Vertical  Helical  Scan 

VHSIC 

Very  High  Speed  Integrated  Circuit 

VISA 

Virtual  Instrument  Standard  Architecture 

VITC 

Vertical  Interval  Time  Code 

VITD 

VPF  Interim  Terrain  Data 

VLF 

Very  Low  Frequency 

VMap 

Vector  Map 

VME 

Virtual  Memory  Extended 

VMF 

Variable  Message  Format 

VoIP 

Voice  Over  Internet  Protocol 

VPF 

Vector  Product  Format 

VPN 

Virtual  Private  Network 

VPP 

VXI  plug  &  play 

VRML 

Virtual  Reality  Modeling  Language 

VSM 

Video  Systems  Matrix 

VTC 

Video  Teleconferencing 
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VTU 

Video  Teleconferencing  Unit 

VXI 

VME  Extensions  for  Instrumentation 

W3C 

World  Wide  Web  Consortium 

WGS 

World  Geodetic  System 

WMO 

World  Meteorological  Organization 

WS 

Weapon  Systems 

WSHCI 

Weapon  Systems  Human-Computer  Interface 

WSTAWG 

Weapons  Systems  Technical  Architecture  Working  Group 

WIVSPLUS 

World  Vector  Shoreline  Plus 

WWW 

World  Wide  Web 

XHTML 

Extensible  HyperText  Markup  Language 

XMI 

XML  Metadata  Interchange 

XML 

Extensible  Markup  Language 

XPATH 

XML  Path  Language 

XSL 

XML  Stylesheet  Language 

XSLT 

XML  Stylesheet  Language  Transformations 
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Note:  Where  two  textual  valiants  of  the  same  term,  e.g.,  “real  time”  and  “real-time”  occur  in  the 
document,  both  are  shown. 

Access  Control 

Process  of  limiting  access  to  the  resources  of  an  IT  product  only  to  authorized  users,  programs, 
processes,  systems,  or  other  IT  products. 

Accreditation 

The  managerial  authorization  and  approval  granted  to  an  ADP  system  or  network  to  process  sensitive 
data  in  an  operational  environment,  made  on  the  basis  of  a  certification  by  designated  technical 
personnel  of  the  extent  to  which  design  and  implementation  of  the  system  meet  prespecified  technical 
requirements,  e.g.,  TCSEC,  for  achieving  adequate  data  security.  Management  can  accredit  a  system  to 
operate  at  a  higher/lower  level  than  the  risk  level  recommended  (e.g.,  by  the  Requirements  Guideline) 
for  the  certification  level  of  the  system.  If  management  accredits  the  system  to  operate  at  a  higher  level 
than  is  appropriate  for  the  certification  level,  management  is  accepting  the  additional  risk  incurred. 

Activity  Model  (IDEFO) 

A  graphic  description  of  a  system  or  subject  that  is  developed  for  a  specific  puipose  and  from  a  selected 
viewpoint.  A  set  of  one  or  more  IDEFO  diagrams  that  depict  the  functions  of  a  system  or  subject  area 
with  graphics,  text  and  glossary.  (FIPS  Pub  183,  Integration  Definition  For  Function  Modeling 
(IDEFO),  December  1993) 

Aggregate-Level  Simulation  Protocol  (ALSP) 

A  family  of  simulation  interface  protocols  and  supporting  infrastructure  software  that  permit  the 
integration  of  distinct  simulations  and  war  games.  Combined,  the  interface  protocols  and  software 
enable  large-scale,  distributed  simulations  and  war  games  of  different  domains  to  interact  at  the  combat 
object  and  event  level.  The  most  widely  known  example  of  an  AFSP  confederation  is  the  Joint/Service 
Training  Confederation  (CBS,  AWSIM,  JECEWSI,  RESA,  MTWS,  TACSIM,  CSSTSS)  that  has 
provided  the  backbone  to  many  large,  distributed,  simulation-supported  exercises.  Other  examples  of 
ALSP  confederations  include  confederations  of  analytical  models  that  have  been  formed  to  support 
U.S.  Air  Force,  U.S.  Army,  and  U.S.  TRANSCOM  studies.  (DoD  5000.59-P,  “Modeling  and 
Simulation  Master  Plan,”  October  1995,  authorized  by  DoD  Directive  5000.59,  January  4,  1994) 

American  National  Standards  Institute  (ANSI) 

The  principal  standards  coordination  body  in  the  U.S.  ANSI  is  a  member  of  the  ISO. 

Application  Platform 

□  The  collection  of  hardware  and  software  components  that  provide  the  services  used  by  support 
and  mission-specific  software  applications.  (TRM) 

□  The  application  platform  is  defined  as  the  set  of  resources  that  support  the  services  on  which 
application  software  will  execute.  It  provides  services  at  its  interfaces  that,  as  much  as  possible, 
make  the  implementation-specific  characteristics  of  the  platform  transparent  to  the  application 
software.  (TRM) 
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Application  Platform  Entity 

The  term  ‘application  platform  entity’  is  used  when  referencing  the  TRM,  as  opposed  to  referencing  an 
actual  hardware  platform  (physical  implementation).  (TRM) 

Application  Program  Interface  (API) 

□  The  interface,  or  set  of  functions,  between  the  application  software  and  the  application 
platform.  (NIST  Special  Publication  500-230;  TRM) 

□  The  means  by  which  an  application  designer  enters  and  retrieves  information.  (TRM) 

Application  Software  Entity 

Mission-area  and  support  applications.  A  common  set  of  support  applications  forms  the  basis  for  the 
development  of  mission-area  applications.  Mission-area  applications  should  be  designed  and 
developed  to  access  this  set  of  common  support  applications.  Applications  access  the  Application 
Platform  via  a  standard  set  of  APIs.  (TRM) 

Architecture 

Architecture  has  various  meanings,  depending  upon  its  contextual  usage.  (1)  The  structure  of 
components,  their  interrelationships,  and  the  principles  and  guidelines  governing  their  design  and 
evolution  over  time.  (2)  Organizational  structure  of  a  system  or  component.  (IEEE  STD  610.12-1990; 
TRM)  or; 

An  architecture  is  a  composition  of  (1)  components  (including  humans)  with  their  functionality  defined 
(Technical),  (2)  requirements  that  have  been  configured  to  achieve  a  prescribed  purpose  or  mission 
(Operational),  and  (3)  their  connectivity  with  the  information  flow  defined.  (OSJTF) 

Authentication 

□  To  verify  the  identity  of  a  user,  device,  or  other  entity  in  a  computer  system,  often  as  a 
prerequisite  to  allowing  access  to  resources  in  a  system. 

□  To  verify  the  integrity  of  data  that  have  been  stored,  transmitted,  or  otherwise  exposed  to 
possible  unauthorized  modification. 

Authentication  Servers 

A  server  designed  using  security  measures  to  establish  the  validity  of  a  transmission,  message  or 
originator,  or  a  means  of  verifying  an  individual’s  eligibility  to  receive  specific  categories  of 
information. 

CBR 

Circuit  (voice  and  telephony)  traffic  over  ATM. 

Character-Based  Interface 

A  non-bit-mapped  user  interface  in  which  the  primary  form  of  interaction  between  the  user  and  system 
is  through  text. 

Combatant  Command 

A  unified  or  specified  command  with  a  broad  continuing  mission  under  a  single  commander  established 
and  so  designated  by  the  President,  through  the  Secretary  of  Defense  with  the  advice  and  assistance  of 
the  Chairman  of  the  Joint  Chiefs  of  Staff.  Combatant  commands  typically  have  geographic  or 
functional  responsibilities.  [Joint  Pub  1-02  http://www.dtic.mil/doctrine/jel/doddict1 
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Unless  otherwise  directed  by  the  President  or  Secretary  of  Defense,  the  authority,  direction,  and  control 
of  the  Commander  of  a  Unified  or  Specified  Combatant  Command  with  respect  to  all  the  commands 
and  forces  assigned  to  that  command  [including  Headquarters,  Service,  and  Agency  Components] 
include  the  command  functions  of  giving  authoritative  direction  to  subordinate  commands  and  forces 
necessary  to  carry  out  missions  assigned  to  the  command.  [Source:  DoD  Directive  5100.1,  “Functions 
of  the  Department  of  Defense  and  Its  Major  Commands,”  September  25,  1987]. 

Command  and  Control 

The  exercise  of  authority  and  direction  by  a  properly  designated  commander  over  assigned  and  attached 
forces  in  the  accomplishment  of  the  mission.  Command  and  control  functions  are  performed  through  an 
arrangement  of  personnel,  equipment,  communications,  facilities,  and  procedures  employed  by  a 
commander  in  planning,  directing,  coordinating,  and  controlling  forces  and  operations  in  the 
accomplishment  of  the  mission.  Also  called  C2.  (Joint  Pub  1-02 
http://www.dtic.mil/doctrine/jel/doddict) 

Command,  Control,  Communications,  and  Computer  Systems 

Integrated  systems  of  doctrine,  procedures,  organizational  structures,  personnel,  equipment,  facilities, 
and  communications  designed  to  support  a  commander’s  exercise  of  command  and  control  across  the 
range  of  military  operations.  Also  called  C4  systems.  (Joint  Pub  1-02 
http :  //w  w  w.dtic .  mil/doctrine/j  el/doddict) 

Commercial  Item 

□  Any  item  customarily  used  by  the  general  public  for  other  than  governmental  purposes,  that  has 
been  sold,  leased,  or  licensed  to  the  general  public,  or  that  has  been  offered  for  sale,  lease,  or 
license  to  the  general  public. 

□  Any  item  that  evolved  from  an  item  described  above  through  advances  in  technology  or 
performance  that  is  not  yet  available  in  the  commercial  market,  but  will  be  available  in  time  to 
meet  the  delivery  requirements  of  the  solicitation. 

□  Any  item  that,  but  for  modifications  of  a  type  customarily  available  in  the  commercial  market 
or  minor  modifications  made  to  meet  DoD  requirements,  would  satisfy  the  criteria  above. 

□  Any  combination  of  items  meeting  the  requirements  above  or  below  that  are  of  a  type 
customarily  combined  and  sold  in  combination  to  the  general  public. 

□  Installation  services,  maintenance  services,  repair  services,  training  services,  and  other  services 
if  such  services  are  procured  for  support  of  any  item  referred  to  above,  if  the  sources  of  such 
services: 

■  offers  such  services  to  the  general  public  and  DoD  simultaneously  and  under  similar  terms 
and  conditions  and 

■  offers  to  use  the  same  work  force  for  providing  DoD  with  such  services  as  the  source  used 
for  providing  such  services  to  the  general  public. 

□  Services  offered  and  sold  competitively,  in  substantial  quantities,  in  the  commercial 
marketplace  based  on  established  catalog  prices  of  specific  tasks  performed  and  under  standard 
commercial  terms  and  conditions. 

□  Any  item,  combination  of  items,  or  service  referred  to  above  notwithstanding  the  fact  that  the 
item  or  service  is  transferred  between  or  among  separate  divisions,  subsidiaries,  or  affiliates  of 
a  contractor. 

□  A  nondevelopmental  item  developed  exclusively  at  private  expense  and  sold  in  substantial 
quantities,  on  a  competitive  basis,  to  State  and  local  governments. 
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(Standardization  Document  [SD-2],  Buying  Commercial  and  Nondevelopmental  Items:  A  Handbook. 
Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology,  April  1996.) 

Commercial  off-the-Shelf  (COTS) 

□  See  the  definition  of  Commercial  Item  found  above.  (OSJTF  1995). 

□  Refers  to  an  item  of  hardware  or  software  that  has  been  produced  by  a  contractor  and  is 
available  for  general  purchase.  Such  items  are  at  the  unit  level  or  higher.  Such  items  must  have 
been  sold  and  delivered  to  government  or  commercial  customers,  must  have  passed  customer’s 
acceptance  testing,  be  operating  under  customer’s  control,  and  within  the  user  environment. 
Further,  such  items  must  have  meaningful  reliability,  maintainability,  and  logistics  historical 
data.  (TRM) 

Compliance 

Compliance  is  enumerated  in  an  implementation/migration  plan.  A  system  is  compliant  with  the  JTA  if 
it  meets,  or  is  implementing,  an  approved  plan  to  meet  all  applicable  JTA  mandates. 

Conceptual  Model  of  the  Mission  Space  (CMMS) 

One  of  the  three  components  of  the  DoD  Common  Technical  Framework  (CTF).  They  are  first 
abstractions  of  the  real  world  and  serve  as  a  frame  of  reference  for  simulation  development  by  capturing 
the  basic  information  about  important  entities  involved  in  any  mission  and  their  key  actions  and 
interactions.  They  arc  simulation-neutral  views  of  those  entities,  actions,  and  interactions  occurring  in 
the  real  world.  (DoD  5000.59-P,  “Modeling  and  Simulation  Master  Plan,”  October  1995,  authorized  by 
DoD  Directive  5000.59,  January  4,  1994) 

Confidentiality 

□  The  property  that  information  is  not  made  available  or  disclosed  to  unauthorized  individuals, 
entities,  or  processes.  (Source:  RFC  2828,  Internet  Security  Glossary,  May  2000) 

□  Assurance  that  information  is  not  disclosed  to  unauthorized  entities  or  processes.  (Source: 
National  Security  Telecommunications  and  Information  Systems  Security  Instruction 
(NSTISSI)  4009) 

Configuration  Management 

A  discipline  applying  technical  and  administrative  direction  and  surveillance  to:  (1)  identify  and 
document  the  functional  and  physical  characteristics  of  a  configuration  item,  (2)  control  changes  to 
those  characteristics,  and  (3)  record  and  report  changes  to  processing  and  implementation  status. 
(TRM) 

Coordinated  Universal  Time  (UTC) 

Time  scale,  based  on  the  second  (SI),  as  defined  and  recommended  by  the  CCIR  and  maintained  by  the 
Bureau  International  des  Poids  et  Mesures  (BIPM). 

Cryptographic  Algorithms 

An  algorithm  that  employs  the  science  of  cryptography,  including  encryption  algorithms,  cryptographic 
hash  algorithms,  digital  signature  algorithms,  and  key  agreement  algorithms. 

Cryptographic  APIs 

The  source  code  formats  and  procedures  through  which  an  application  program  accesses  cryptographic 
services,  which  arc  defined  abstractly  compared  to  their  actual  implementation. 
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Cryptographic  Modules 

A  set  of  hardware,  software,  firmware,  or  some  combination  thereof  that  implements  cryptographic 
logic  or  processes,  including  cryptographic  algorithms,  and  is  contained  within  the  module’s 
cryptographic  boundary,  which  is  an  explicitly  defined  contiguous  perimeter  that  establishes  the 
physical  bounds  of  the  module. 

Cryptographic  Key  Algorithms 

An  algorithm  that  develops  a  sequence  of  symbols  that  controls  the  operations  of  encipherment  and 
decipherment 

Cryptographic  Tokens 

A  portable,  user  controlled,  physical  device  used  to  store  cryptographic  information  and  possibility 
perform  cryptographic  functions. 

Data  Dictionary 

A  specialized  type  of  database  containing  metadata  that  is  managed  by  a  data  dictionary  system;  a 
repository  of  information  describing  the  characteristics  of  data  used  to  design,  monitor,  document, 
protect,  and  control  data  in  information  systems  and  databases;  an  application  of  a  data  dictionary 
system.  (DoD  8320.1-M-l,  “Data  Element  Standardization  Procedures,”  January  15,  1993,  authorized 
by  DoD  Directive  8320.1,  September  26,  1991) 

Data  Integrity 

□  The  state  that  exists  when  computerized  data  is  the  same  as  that  in  the  source  documents  and 
has  not  been  exposed  to  accidental  or  malicious  alteration  or  destruction. 

□  The  property  that  data  has  not  been  exposed  to  accidental  or  malicious  alteration  or  destruction. 

Data  Model 

In  a  database,  the  user’s  logical  view  of  the  data  in  contrast  to  the  physically  stored  data,  or  storage 
structure.  A  description  of  the  organization  of  data  in  a  manner  that  reflects  the  information  structure  of 
an  enterprise.  (DoD  8320.1-M-l,  “Data  Element  Standardization  Procedures,”  January  15,  1993, 
authorized  by  DoD  Directive  8320.1,  September  26,  1991) 

Designated  Approving  Authority  (DAA) 

The  official  with  the  authority  to  formally  assume  responsibility  for  operating  an  Automated 
Information  System  (AIS)  or  network  at  an  acceptable  level  of  risk.  (NSTISSI  No.  4009) 

Digital  Signature 

The  digital  signature  allows  a  message  originator  to  sign  (cover)  data  (e.g.,  the  Hash  value).  This 
provides  the  recipient  with  the  means  to  verify  the  identity  of  the  originator  (user  authentication  and 
non-repudiation). 

Directory  Service 

A  Directory  Service  provides  names,  locations  and  other  information  about  people  and  organizations. 
In  a  LAN  or  WAN,  this  directory  information  may  be  used  for  e-mail  addressing,  user  authentication 
(e.g.,  logins  and  passwords),  or  network  security  (e.g.,  user-access  rights).  A  directory  may  also  contain 
information  on  the  physical  devices  on  a  network  (e.g.,  PCs,  servers,  printers,  routers  and 
communication  servers)  and  the  services  available  on  a  specific  device  (such  as  operating  systems, 
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applications,  shared-file  systems,  print  queues).  This  information  may  be  accessible  to  computer 
applications  as  well  as  being  eye-readable  for  end  users. 

Distributed  Interactive  Simulation  (DIS) 

Program  to  electronically  link  organizations  operating  in  the  four  domains:  advanced  concepts  and 
requirements;  military  operations;  research,  development,  and  acquisition;  and  training.  A  synthetic 
environment  within  which  humans  may  interact  through  simulation(s)  at  multiple  sites  networked  using 
compliant  architecture,  modeling,  protocols,  standards,  and  databases.  (DoD  5000.59-P,  “Modeling 
and  Simulation  Master  Plan,”  October  1995,  authorized  by  DoD  Directive  5000.59,  January  4,  1994) 

Domain 

A  distinct  functional  area  that  can  be  supported  by  a  family  of  systems  with  similar  requirements  and 
capabilities.  An  area  of  common  operational  and  functional  requirements. 

Element 

A  service  area,  interface,  or  standard  within  the  JTA  document.  The  definitions  below  are  abbreviated 
versions  of  those  appearing  elsewhere  in  the  JTA  Glossary. 

□  Service  Area  -  a  set  of  system  capabilities  grouped  by  functional  areas.  Both  the  DoD 
Technical  Reference  Model  and  the  JTA  define  set(s)  of  service  areas  common  to  every 
system. 

□  Interface  -  a  boundary  between  two  functional  areas  in  a  reference  model. 

□  Standard  -  a  document  that  establishes  uniform  engineering  and  technical  requirements.  The 
mandated  standards  in  the  JTA  are  grouped  by  their  applicable  service  areas. 

Electronic  Business/Electronic  Commerce 

The  interchange  and  processing  of  information  via  electronic  techniques  for  accomplishing  transactions 
based  upon  the  application  of  commercial  standards  and  practices.  An  integral  part  of  implementing 
EB/EC  is  the  application  of  business  process  improvement  or  reengineering  to  streamline  business 
processes  prior  to  the  incorporation  of  technologies  facilitating  the  electronic  exchange  of  business 
information. 

External  Environment  Interface  (EEI) 

The  interface  that  supports  information  transfer  between  the  application  platform  and  the  external 
environment.  (NIST  Special  Publication  500-230;  TRM) 

Federate 

A  member  of  an  HLA  Federation.  All  applications  participating  in  a  Federation  are  called  Federates.  In 
reality,  this  may  include  Federate  Managers,  data  collectors,  live  entity  surrogates,  simulations,  or 
passive  viewers.  See  HFA  Glossary:  <https://www.dmso.mil/public>. 

Federation 

A  named  set  of  interacting  federates,  a  common  federation  object  model,  and  supporting  RTI,  that  are 
used  as  a  whole  to  achieve  some  specific  objective.  See  HFA  Glossary: 
<https://www.dmso.mil/public>. 
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Federation  Object  Model  (FOM) 

An  identification  of  the  essential  classes  of  objects,  object  attributes,  and  object  interactions  that  arc 
supported  by  an  HLA  federation.  In  addition,  optional  classes  of  additional  information  may  also  be 
specified  to  achieve  a  more  complete  description  of  the  federation  structure  and/or  behavior.  See  HLA 
Glossary:  <https://www.dmso.mil/public>. 

Firewall 

A  system  or  combination  of  systems  that  enforces  a  boundary  between  two  or  more  networks. 

Government  off-the-shelf  (GOTS) 

Software  applications,  modules,  or  objects  developed  for  Government  departments  or  agencies  and 
subsequently  made  available  to  other  Government  entities.  GOTS  software  often  will  be  found  in  reuse 
repositories  maintained  to  facilitate  and  encourage  its  distribution  and  use. 

Graphical  User  Interface  (GUI) 

System  design  that  allows  the  user  to  effect  commands,  enter  into  transaction  sequences,  and  receive 
displayed  information  through  graphical  representations  of  objects  (menus,  screens,  buttons,  etc.). 

Guards 

Highly  assured  devices  that  negotiate  the  transfer  of  data  between  enclaves  operating  at  different 
security  levels. 

Hash 

The  Hash  function  provides  a  check  for  data  integrity. 

Hash  Algorithms 

Algorithms  developed  to  compute  values  using  parity  or  hashing  for  information  requiring  protection 
against  error  or  manipulation. 

High-Level  Architecture  (HLA) 

Major  functional  elements,  interfaces,  and  design  rules,  pertaining  as  feasible  to  all  DoD  simulation 
applications,  and  providing  a  common  framework  within  which  specific  system  architectures  can  be 
defined.  See  HLA  Glossary  at  <https://www.dmso.mil/public>. 

Human-Computer  Interface  (HCI) 

Hardware  and  software  allowing  information  exchange  between  the  user  and  the  computer. 

Hybrid  Graphical  User  Interface 

A  GUI  that  is  composed  of  tool  kit  components  from  more  than  one  user  interface  style. 

Imagery 

Collectively,  the  representations  of  objects  reproduced  electronically  or  by  optical  means  on  film, 
electronic  display  devices,  or  other  media.  (JCS) 

Information  Technology  (IT) 

□  The  term  “information  technology,”  with  respect  to  an  executive  agency  means  any  equipment 
or  interconnected  system  or  subsystem  of  equipment  that  is  used  in  the  automatic  acquisition, 
storage,  manipulation,  management,  movement,  control,  display,  switching,  interchange, 
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transmission,  or  reception  of  data  or  information  by  the  executive  agency.  For  purposes  of  the 
preceding  sentence,  equipment  is  used  by  an  executive  agency  if  the  equipment  is  used  by  the 
executive  agency  directly  or  is  used  by  a  contractor  under  a  contract  with  the  executive  agency 
that  (i)  requires  the  use  of  such  equipment,  or  (ii)  requires  the  use,  to  a  significant  extent,  of 
such  equipment  in  the  performance  of  a  service  or  the  furnishing  of  a  product. 

□  The  term  “information  technology”  includes  computers,  ancillary  equipment,  software, 
firmware  and  similar  procedures,  services  (including  support  services),  and  related  resources. 

□  Notwithstanding  the  subparagraphs  above  the  term  “information  technology”  does  not  include 
any  equipment  that  is  acquired  by  a  Federal  contractor  incidental  to  a  Federal  contract. 
(Information  Technology  Management  Reform  Act  of  1996.  See:  <http://www.c3i.osd.mil>. 

Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 

An  accredited  standards  body  that  has  produced  standards  such  as  the  network-oriented  802  protocols 
and  POSIX.  Members  represent  an  international  cross-section  of  users,  vendors,  and  engineering 
professionals.  (TRM) 

Intelligence 

□  The  product  resulting  from  the  collection,  processing,  integration,  analysis,  evaluation,  and 
interpretation  of  available  information  concerning  foreign  countries  or  areas. 

□  Information  and  knowledge  about  an  adversary  obtained  through  observation,  investigation, 
analysis,  or  understanding.  (Joint  Pub  1-02  http://www.dtic.mil/doctrine/jel/doddict) 

Interactive  Model 

A  model  that  requires  human  participation.  Syn:  human-in-the-loop.  (“A  Glossary  of  Modeling  and 
Simulation  Terms  for  Distributed  Interactive  Simulation  (DIS),”  August,  1995) 

Interconnections 

The  manual,  electrical,  electronic,  or  optical  communications  paths/linkages  between  the  systems. 
Includes  the  circuits,  networks,  relay  platforms,  switches,  etc.,  necessary  for  effective  communications. 

Interface 

A  shared  boundary  between  two  functional  units.  A  functional  unit  is  referred  to  as  a  entity  when 
discussing  the  classification  of  items  related  to  application  portability. 

International  Electrotechnical  Commission  (IEC) 

An  international  standards  body  similar  to  ISO,  but  limited  by  its  charter  to  standards  in  the  electrical 
and  electrotechnical  areas.  In  1987,  the  ISO  and  IEC  merged  ISO  Technical  Committee  97  and  IEC 
Technical  Committees  47B  and  83  to  form  ISO/IEC  Joint  Technical  Committee  (JTC)  1,  which  is  the 
only  internationally  recognized  committee  dealing  exclusively  with  information  technology  standards. 

International  Organization  for  Standardization  (ISO) 

The  International  Organization  for  Standardization  (ISO)  is  a  worldwide  federation  of  national 
standards  bodies  from  some  100  countries,  one  from  each  country.  ISO  is  a  non-governmental 
organization,  established  to  promote  the  development  of  standardization  and  related  activities  in  the 
world  with  a  view  to  facilitating  the  international  exchange  of  goods  and  services,  and  to  developing 
cooperation  in  the  spheres  of  intellectual,  scientific,  technological,  and  economic  activity.  ISO’s  work 
results  in  international  agreements,  which  arc  published  as  International  Standards. 
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International  Telecommunications  Union  -  Telecommunications  Standardization  Sector  (ITU-T) 

ITU-T,  formerly  called  the  Comite  Consultatif  International  de  Telegraphique  et  Telephonique 
(CCITT),  is  part  of  the  International  Telecommunications  Union,  a  United  Nations  treaty  organization. 
Membership  and  participation  in  ITU-T  is  open  to  private  companies;  scientific  and  trade  associations; 
and  postal,  telephone,  and  telegraph  administrations.  Scientific  and  industrial  organizations  can 
participate  as  observers.  The  U.S.  representative  to  ITU-T  is  provided  by  the  Department  of  State. 
Since  ITU-T  does  not  have  the  authority  of  a  standards  body  nor  the  authority  to  prescribe 
implementation  of  the  documents  it  produces,  its  documents  are  called  recommendations  rather  than 
standards. 

Internet  Engineering  Task  Force  (IETF) 

The  Internet  Engineering  Task  Force  (IETF)  is  a  large  open  international  community  of  network 
designers,  operators,  vendors,  and  researchers  concerned  with  the  evolution  of  the  Internet  architecture 
and  the  smooth  operation  of  the  Internet.  The  actual  technical  work  of  the  IETF  is  done  in  its  working 
groups,  which  arc  organized  by  topic  into  several  areas  (e.g.,  routing,  transport,  security).  The  IETF  is 
a  subdivision  of  the  Internet  Architecture  Board  (IAB)  responsible  for  the  development  of  protocols, 
their  implementations,  and  standardization. 

Internet  Protocol  Security  Services 

Services  that  provide  specific  security  architecture  and  protocols  that  provide  security  services  for 
Internet  Protocol  traffic. 

Interoperability 

□  The  ability  of  two  or  more  systems  or  components  to  exchange  data  and  use  information. 
(IEEE  STD  610.12) 

□  The  ability  of  two  or  more  systems  to  exchange  information  and  to  mutually  use  the 
information  that  has  been  exchanged.  (Army  Science  Board) 

Interworking 

The  exchange  of  meaningful  information  between  computing  elements  (semantic  integration),  as 
opposed  to  interoperability,  which  provides  syntactic  integration  among  computing  elements. 

Intrusion  Detection  System 

An  intrusion  is  an  attempt  to  break  into  or  misuse  your  system.  An  intrusion  detection  system,  attempts 
to  detect  an  intruder  breaking  into  your  system  or  a  legitimate  user  misusing  system  resources.  The 
intrusion  detection  system  should  run  constantly  on  your  system,  working  away  in  the  background,  and 
only  notifying  you  when  it  detects  something  it  considers  suspicious  or  illegal.  What  is  suspicious  or 
illegal  depends  on  the  security  policy  you  have  established  for  the  system. 

Joint  Task  Force 

A  joint  force  that  is  constituted  and  so  designated  by  the  Secretary  of  Defense,  a  combatant  commander, 
a  subunified  commander,  or  an  existing  joint  task  force  commander.  Also  called  JTF.  [Source — 

Joint  Pub  1-02  http://www.dtic.mil/doctrine/iel/doddict1  [The  JTF  includes  a  Headquarters  element  and 
all  of  the  Service  Expeditionary  Forces  that  support  the  Joint  Task  Force  mission.] 
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Joint  Technical  Committee  (JTC)  1 

JTC1  was  formed  in  1987  by  merger  of  ISO  Technical  Committee  97  and  IEC  Technical 
Committees  47B  and  83  to  avoid  development  of  possibly  incompatible  information  technology 
standards  by  ISO  and  IEC.  ANSI  represents  the  U.S.  government  in  ISO  and  JTC1. 

Key  Exchange 

The  key  is  securely  transmitted  to  the  recipient  by  a  secure  Key  Exchange.  The  Key  Exchange  process 
wraps  (similar  to  encrypt)  the  key  necessary  to  implement  the  encryption  algorithm. 

Key  Management  Infrastructure 

The  process  of  handling  and  controlling  cryptographic  keys  and  related  material  (such  as  initialization 
values)  during  their  life  cycle  in  a  cryptographic  system,  including  ordering,  generating,  distributing, 
storing,  loading,  escrowing,  archiving,  auditing,  and  destroying  material. 

Legacy  Environments 

Legacy  environments  could  be  called  legacy  architectures  or  infrastructures  and  as  a  minimum  consist 
of  a  hardware  platform  and  an  operating  system.  Legacy  environments  arc  identified  for  phase-out, 
upgrade,  or  replacement.  All  data  and  applications  software  that  operate  in  a  legacy  environment  must 
be  categorized  for  phase-out,  upgrade,  or  replacement.  (TRM) 

Legacy  Standard 

A  JTA  standard  that  is  a  candidate  for  phase-out,  upgrade,  or  replacement.  A  legacy  standard  may  be 
an  obsolete  standard  without  an  upgrade  path,  or  an  older  version  of  a  currently  mandated  JTA 
standard.  A  legacy  standard  is  generally  associated  with  an  existing  or  “legacy  system,”  although  it  may 
be  necessary  in  a  new  or  upgraded  system  when  an  interface  to  a  legacy  system  is  required.  (JTADG) 

Legacy  Systems 

Systems  that  are  candidates  for  phase-out,  upgrade,  or  replacement.  Generally  legacy  systems  arc  in 
this  category  because  they  do  not  comply  with  data  standards  or  other  standards.  Legacy  system 
workloads  must  be  converted,  transitioned,  or  phased  out  (eliminated).  Such  systems  may  or  may  not 
operate  in  a  legacy  environment.  (TRM) 

Link  Layer 

Layer  2  of  the  OSI  7  Layer  Reference  Model  where  a  point-to-point  communication  channel 
connecting  two  sub-network  relays  is  established.  Lrorn  ISO  7498,  the  OSI  Reference  Model:  The  Data 
Link  Layer  provides  functional  and  procedural  means  for  connectionless  mode  among  network  entities, 
and  for  connection  mode  for  the  establishment,  maintenance,  and  release  data-link-connections  among 
network  entities  and  for  the  transfer  of  data-link  service  data  units.  A  data-link  connection  is  built  upon 
one  or  several  physical-connections.  The  Data  Link  Layer  detects  and  possibly  corrects  errors  that  may 
occur  in  the  Physical  Layer.  In  addition,  the  Data  Link  Layer  enables  the  Network  Layer  to  control  the 
interconnection  of  data  circuits  within  the  Physical  Layer. 

Live,  Virtual,  and  Constructive  Simulation 

The  categorization  of  simulation  into  live,  virtual,  and  constructive  is  problematic  because  there  is  no 
cleai-  division  between  these  categories.  The  degree  of  human  participation  in  the  simulation  is 
infinitely  variable,  as  is  the  degree  of  equipment  realism.  This  categorization  of  simulations  also  suffers 
by  excluding  a  category  for  simulated  people  working  real  equipment  (e.g.,  smart  vehicles). 
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(DoD  5000.59-P,  “Modeling  and  Simulation  Master  Plan,”  October  1995,  authorized  by  DoD 
Directive  5000.59,  January  4,  1994) 

□  Live  Simulation.  A  simulation  involving  real  people  operating  real  systems. 

□  Virtual  Simulation.  A  simulation  involving  real  people  operating  simulated  systems.  Virtual 
simulations  inject  human-in-the-loop  (HITL)  in  a  central  role  by  exercising  motor  control  skills 
(e.g.,  flying  an  airplane),  decision  skills  (e.g.,  committing  fire  control  resources  to  action),  or 
communication  skills  (e.g.,  as  members  of  a  C4I  team) 

□  Constructive  Model  or  Simulation.  Models  and  simulations  that  involve  simulated  people 
operating  simulated  systems.  Real  people  stimulate  (make  inputs)  to  such  simulations,  but  are 
not  involved  in  determining  the  outcomes. 

Market  Acceptance 

Means  that  an  item  has  been  accepted  in  the  market  as  evidenced  by  annual  sales,  length  of  time 
available  for  sale,  and  after-sale  support  capability.  (SD-2,  April  1996) 

Metadata 

Information  describing  the  characteristics  of  data;  data  or  information  about  data;  descriptive 
information  about  an  organization’s  data,  data  activities,  systems,  and  holdings.  (DoD  8320.1-M-l, 
Data  Standardization  Procedures,  August  1997) 

Model 

A  physical,  mathematical,  or  otherwise  logical  representation  of  a  system,  entity,  phenomenon,  or 
process.  (“A  Glossary  of  Modeling  and  Simulation  Terms  for  Distributed  Interactive  Simulation 
(DIS),”  August,  (DoD  Directive  5000.59,  “DoD  Modeling  and  Simulation  (M&S)  Management,” 
January  4,  1994);  (DoD  5000.59-P,  “Modeling  and  Simulation  Master  Plan,”  October  1995,  authorized 
by  DoD  Directive  5000.59,  January  4,  1994). 

Modeling  and  Simulation  (M&S) 

The  use  of  models,  including  emulators,  prototypes,  simulators,  and  stimulators,  either  statically  or  over 
time,  to  develop  data  as  a  basis  for  making  managerial  or  technical  decisions.  The  terms  “modeling” 
and  “simulation”  are  often  used  interchangeably.  (“M&S  Educational  Training  Tool  (MSETT),  Navy 
Air  Weapons  Center  Training  Systems  Division  Glossary,”  April  28,  1994) 

Motif 

User  interface  design  approach  based  upon  the  “look  and  feel”  presented  in  the  OSF/Motif  style  guide. 
Motif  is  marketed  by  the  Open  Software  Foundation. 

Multimedia 

The  presentation  of  information  on  a  medium  using  any  combination  of  video,  sound,  graphics, 
animation,  and  text;  using  various  input  and  output  devices. 

Naming  Service 

A  Naming  Service  is  used  to  construct  large,  enterprise-wide  naming  graphs  where  Naming  Contexts 
model  “directories”  or  “folders”  and  other  names  identify  “document”  or  “file”  kinds  of  objects.  In 
other  words,  the  naming  service  is  used  as  the  backbone  of  an  enterprise-wide  filing  system.  The 
Naming  Service  provides  the  principal  mechanism  through  which  most  clients  of  an  Object  Request 
Broker-based  system  locate  objects  that  they  intend  to  use  (make  requests  of). 
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National  Institute  of  Standards  and  Technology  (NIST) 

The  division  of  the  U.S.  Department  of  Commerce  that  ensures  standardization  within  Government 
agencies.  NIST  was  formerly  known  as  the  National  Bureau  of  Standards.  NIST  develops  and 
maintains  Federal  Information  Processing  Standards  (FIPS)  PUBS,  the  standards  the  Federal 
Government  uses  in  its  procurement  efforts.  Federal  agencies,  including  DoD,  must  use  these  standards 
where  applicable. 

National  Security  System 

□  The  term  “national  security  system”  means  any  telecommunications  or  information  system 
operated  by  the  United  States  Government,  the  function,  operation,  or  use  of  which: 

(1)  involves  intelligence  activities;  (2)  involves  cryptologic  activities  related  to  national 
security;  (3)  involves  command  and  control  of  military  forces;  (4)  involves  equipment  that  is 
an  integral  part  of  a  weapon  or  weapons  system;  or  (5)  subject  to  subsection  (b),  is  critical  to 
the  direct  fulfillment  of  military  or  intelligence  missions. 

□  LIMITATION. -Subsection  (a)(5)  does  not  include  a  system  that  is  to  be  used  for  routine 
administrative  and  business  applications  (including  payroll,  finance,  logistics,  and  personnel 
management  applications).  Information  Technology  Management  Reform  Act  of  1996.  See: 
<http://www.c3i.osd.mil>. 

Network  Management 

In  simple  terms,  network  management  may  be  defined  as  the  capability  to  track,  monitor  and  control 
network  resources  across  an  entire  network  (i.e.,  in  the  core,  edge,  and  access  portions  of  the  network). 

Effective  network  management  solutions  should  include  the  following: 

□  Fault  management,  to  quickly  identify  potential  network  problems 

□  Configuration  management,  which  involves  changing  network  and  user  configurations  to 
optimize  network  performance  and  productivity 

□  Performance  management,  for  tracking  important  network  events,  projecting  future  upgrade 
requirements  and  troubleshooting 

□  Accounting  management,  to  track  and  bill  network  users  for  their  services  and  software 

□  Security  management,  to  protect  the  network  from  unauthorized  access  to  critical  business 
data. 

Nondevelopmental  Item  (NDI) 

□  Any  previously  developed  item  used  exclusively  for  governmental  puiposes  by  a  U.S.  Federal, 
State  or  Local  government  agency  or  a  foreign  government  with  which  the  U.S.  has  a  mutual 
defense  cooperation  agreement. 

□  Any  item. .  .that  requires  only  minor  modification  in  order  to  meet  the  requirements  of  the 
procuring  agency. 

□  Any  item  currently  being  produced  that  does  not  meet  the  requirement  of. .  .solely  because  the 
item  is  not  yet  in  use. 

Object  Model 

A  specification  of  the  objects  intrinsic  to  a  given  system,  including  a  description  of  the  object 
characteristics  (attributes)  and  a  description  of  the  static  and  dynamic  relationships  (associations)  that 
exist  between  objects.  See  HLA  Glossary:  <https://www.dmso.mil/public>. 
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Open  System 

A  system  that  implements  sufficient  open  specifications  for  interfaces,  services,  and  supporting  formats 
to  enable  properly  engineered  components  to  be  utilized  across  a  wide  range  of  systems  with  minimal 
changes,  to  interoperate  with  other  components  on  local  and  remote  systems,  and  to  interact  with  users 
in  a  style  that  facilitates  portability.  An  open  system  is  characterized  by  the  following: 

□  Well-defined,  widely  used,  non-proprietary  interfaces/protocols 

□  Use  of  standards  developed/adopted  by  industrially  recognized  standards  bodies 

□  Definition  of  all  aspects  of  system  interfaces  to  facilitate  new  or  additional  systems  capabilities 
for  a  wide  range  of  applications 

□  Explicit  provision  for  expansion  or  upgrading  through  the  incorporation  of  additional  or 
higher-performance  elements  with  minimal  impact  on  the  system. 

(IEEE  POSIX  1003.0/D15  as  modified  by  the  Tri-Service  Open  Systems  Architecture  Working  Group) 

Open  Systems  Approach 

An  open  systems  approach  is  a  business  approach  that  emphasizes  commercially  supported  practices, 
products,  specifications,  and  standards.  The  approach  defines,  documents,  and  maintains  a  system 
technical  architecture  that  depicts  the  lowest  level  of  system  configuration  control.  This  architecture 
clearly  identifies  all  the  performance  characteristics  of  the  system  including  those  that  will  be 
accomplished  with  an  implementation  that  references  open  standards  and  specifications.  (OSJTF) 

Operational  Architecture  (OA) 

See  1.5.1. 

Passwords 

Protected/private  character  string  used  to  authenticate  an  entity  or  to  authorize  access  to  data. 

Physical  Layer 

Layer  1  of  the  OSI  7  Layer  Reference  Model  where  a  communication  path  is  established  in  the  physical 
media  for  Open  System  Interconnections  among  two  or  more  physical-entities,  together  with  the 
facilities  necessary  in  the  Physical  Layer  for  the  transmission  of  bits  on  it.  The  Physical  Layer  provides 
the  mechanical,  electrical,  functional,  and  procedural  means  to  activate,  maintain,  and  de-activate 
physical-connections  for  bit  transmission  between  data-link  entities.  A  physical  connection  may 
involve  intermediate  open  systems,  each  relaying  bit  transmission  within  the  Physical  Layer.  Physical 
Layer  entities  are  interconnected  by  means  of  a  physical  medium. 

PKI  Certificates 

Digital  certificates  that  bind  a  system  entity’s  identity  to  a  public-key  value,  and  possibility  to 
additional  data  items;  a  digitally  signed  data  structure  that  attests  to  the  ownership  of  a  public-key. 

Portability 

The  ease  with  which  a  system,  component,  body  of  data,  or  user  can  be  transferred  from  one  hardware 
or  software  environment  to  another.  (TRM) 

Practice 

A  recommended  implementation  or  process  that  further  clarifies  the  implementation  of  a  standard  or  a 
profile  of  a  standard. 
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Profile  of  a  Standard 

An  extension  to  an  existing,  approved  standard  that  further  defines  the  implementation  of  that  standard 
in  order  to  ensure  interoperability.  A  profile  is  generally  more  restrictive  than  the  base  standard  it  was 
extracted  from. 

Protocol  Data  Unit  (PDU) 

DIS  terminology  for  a  unit  of  data  that  is  passed  on  a  network  between  simulation  applications. 

(DoD  5000.59-P,  “Modeling  and  Simulation  Master  Plan,”  October  1995,  authorized  by  DoD 
Directive  5000.59,  January  4,  1994) 

Public  Key  Cryptography 

The  asymmetric  cryptography  used  to  support  the  Public  Key  Infrastructure,  which  is  a  system  of 
Certificate  Authorities  that  perform  some  set  of  certificate  management,  archive  management,  key 
management,  and  token  management  functions  for  a  community  of  users. 

Real  Time,  also  Real-Time 

□  Real-Time  is  a  mode  of  operation.  Real-time  systems  require  events,  data,  and  information  to 
be  available  in  time  for  the  system  to  perform  its  required  course  of  action.  Real-time  operation 
is  characterized  by  scheduled  event,  data,  and  information  meeting  their  acceptable  arrival 
times.  (OSJTF) 

□  Absence  of  delay,  except  for  the  time  required  for  transmission. 

Real-Time  Control  System 

Systems  capable  of  responding  to  external  events  with  negligible  delays. 

Real-Time  Systems 

Systems  that  provide  a  deterministic  response  to  asynchronous  inputs.  (OSJTF) 

Reconnaissance 

A  mission  undertaken  to  obtain,  by  visual  observation  or  other  detection  methods,  information  about 
the  activities  and  resources  of  an  enemy  or  potential  enemy,  or  to  secure  data  concerning  the 
meteorological,  hydrographic,  or  geographic  characteristics  of  a  particular'  area.  (Joint  Pub  1-02 
http  :/Av\vw.dt  ic.mil/doctnnc/jcl/doddict) 

Reference  Model 

A  reference  model  is  a  generally  accepted  abstract  representation  that  allows  users  to  focus  on 
establishing  definitions,  building  common  understandings,  and  identifying  issues  for  resolution.  For 
Warfare  and  Warfare  Support  System  (WWSS)  acquisitions,  a  reference  model  is  necessary  to  establish 
a  context  for  understanding  how  the  disparate  technologies  and  standards  required  to  implement 
WWSS  relate  to  each  other.  Reference  models  provide  a  mechanism  for  identifying  key  issues 
associated  with  portability,  scalability,  and  interoperability.  Most  importantly,  reference  models  will 
aid  in  the  evaluation  and  analysis  of  domain-specific  architectures.  (TRI-SERVICE  Open  Systems 
Architecture  Working  Group). 

Remote  Access 

The  ability  for  a  user  to  log  in  to  a  server  from  a  remote  location.  For  security,  the  user  must  first  be 
authenticated  before  gaining  access. 
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Runtime  Infrastructure  (RTI) 

The  general-purpose  distributed  operating  system  software  that  provides  the  common  interface  services 
during  the  runtime  of  an  HLA  federation.  See  HLA  Glossary:  <http://www.dmso.mil/public>. 

Scalability,  Scaleability 

□  The  capability  to  adapt  hardware  or  software  to  accommodate  changing  work  loads.  (OSJTF) 

□  The  ability  to  use  the  same  application  software  on  many  different  classes  of 
hardware/software  platforms  from  personal  computers  to  super  computers  (extends  the 
portability  concept).  The  ability  to  grow  to  accommodate  increased  work  loads. 

Secondary  Imagery  Dissemination  (SID) 

The  process  for  the  post-collection  electronic  transmission  or  receipt  of  C3I-exploited  non-original 
imagery  and  imagery -products  in  other  than  real-  or  near-real-time. 

Security 

□  The  combination  of  confidentiality,  integrity,  and  availability. 

□  The  quality  or  state  of  being  protected  from  uncontrolled  losses  or  effects.  Note:  Absolute 
security  may  in  practice  be  impossible  to  reach;  thus  the  security  “quality”  could  be  relative. 
Within  state  models  of  security  systems,  security  is  a  specific  “state”  that  is  to  be  preserved 
under  various  operations. 

Security  Algorithms 

Algorithms  developed  to  ensure  message  source  authenticity  and  integrity. 

Service  Area 

A  set  of  capabilities  grouped  into  categories  by  function.  The  JTA  defines  a  set  of  services  common  to 
DoD  information  systems. 

Simulation  Object  Model  (SOM) 

A  specification  of  the  intrinsic  capabilities  that  an  individual  simulation  offers  to  federations.  The 
standard  format  in  which  SOMs  are  expressed  provides  a  means  for  federation  developers  to  quickly 
determine  the  suitability  of  simulation  systems  to  assume  specific  roles  within  a  federation.  See  HLA 
Glossary  at  <https://www.dmso.mil/public>. 

Specification 

A  document  prepared  to  support  acquisition  that  describes  the  essential  technical  requirements  for 
purchased  materiel  and  the  criteria  for  determining  whether  those  requirements  are  met. 

(DoD  4120.3-M) 

Standard 

A  document  that  establishes  uniform  engineering  or  technical  criteria,  methods,  processes,  and 
practices.  (DoD  4120.24-M) 

Standards-Based  Architecture 

An  architecture  based  on  an  acceptable  set  of  standards  governing  the  arrangement,  interaction,  and 
interdependence  of  the  parts  or  elements  that  together  may  be  used  to  form  a  weapon  system,  and  whose 
purpose  is  to  ensure  that  a  conformant  system  satisfies  a  specified  set  of  requirements.  (OSJTF) 
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Standards  Profile 

A  set  of  one  or  more  base  standards  and,  where  applicable,  the  identification  of  those  classes,  subsets, 
options,  and  parameters  of  those  base  standards  necessary  for  accomplishing  a  particular  function. 
(TRM) 

Standard  Simulator  Database  Interchange  Format  (SIF) 

A  DoD  data  exchange  standard  (MIL-STD-1821)  adopted  as  an  input/output  vehicle  for  sharing 
externally  created  simulator  databases  among  the  operational  system  training  and  mission  rehearsal 
communities. 

Surveillance 

The  systematic  observation  of  aerospace,  surface  or  subsurface  areas,  places,  persons,  or  things,  by 
visual,  aural,  electronic,  photographic,  or  other  means.  (Joint  Pub  1-02 
http://www.dtic.mil/doctrine/jel/doddict) 

Synthetic  Environment  Data  Representation  and  Interchange  Specification  (SEDRIS) 

The  specification  encompasses  a  robust  data  model,  data  dictionary,  and  interchange  format  supported 
by  read-and-write  application  programmer’s  interfaces  (APIs),  data  viewers,  a  data  model  browser,  and 
analytical  verification  and  validation  data  model  compliance  tools. 

Synthetic  Environments  (SE) 

Interneted  simulations  that  represent  activities  at  a  high  level  of  realism  from  simulations  of  theaters  of 
war  to  factories  and  manufacturing  processes.  These  environments  may  be  created  within  a  single 
computer  or  a  vast  distributed  network  connected  by  local  and  wide  area  networks  and  augmented  by 
super-realistic  special  effects  and  accurate  behavioral  models.  They  allow  visualization  of  and 
immersion  into  the  environment  being  simulated.  (DoD  5000.59-P,  “Modeling  and  Simulation  Master 
Plan,”  October  1995,  authorized  by  DoD  Directive  5000.59,  January  4,  1994);  (CJCSI  8510.01, 
Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  8510.01,  “Joint  Modeling  and  Simulation 
Management,”  February  17,  1995) 

System 

□  People,  machines,  and  methods  organized  to  accomplish  a  set  of  specific  functions. 

□  An  integrated  composite  of  people,  products,  and  processes  that  provides  a  capability  or 
satisfies  a  stated  need  or  objective. 

Systems  Architecture  (SA) 

See  1.5.3. 

Technical  Architecture  (TA) 

See  1.5.2. 

Technical  Reference  Model  (TRM) 

A  conceptual  framework  that  provides  the  following: 

□  A  consistent  set  of  service  and  interface  categories  and  relationships  used  to  address 
interoperability  and  open  system  issues. 

□  Conceptual  entities  that  establish  a  common  vocabulary  to  better  describe,  compare,  and 
contrast  systems  and  components. 
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□  A  basis  (an  aid)  for  the  identification,  comparison,  and  selection  of  existing  and  emerging 
standards  and  their  relationships. 

□  The  framework  is  not  an  architecture,  is  not  a  set  of  standards,  and  does  not  contain  standards. 

Video 

Electro-Optical  imaging  sensors  and  systems  that  generate  sequential  or  continuous  streaming  imagery 
at  specified  rates.  Video  standards  are  developed  by  recognized  bodies  such  as  ISO,  ITU,  SMPTE, 
EBU,  etc. 

Virtual  Private  Networks 

A  way  of  using  a  public  network  (typically  the  Internet)  to  provide  a  restricted-use  logical  computer 
network  to  link  two  sites  of  an  organization. 

Virus  Code  Detection 

A  system  that  can  detect  a  virus  which  is  a  program  or  code  that  replicates,  that  is  infects  another 
program,  boot  sector,  partition  sector  or  document  that  supports  macros  by  inserting  itself  or  attaching 
itself  to  that  medium.  Most  viruses  just  replicate,  a  lot  also  do  damage. 

Weapon  Systems 

A  combination  of  one  or  more  weapons  with  all  related  equipment,  materials,  services,  personnel  and 
means  of  delivery  and  deployment  (if  applicable)  required  for  self  sufficiency.  (Joint  Pub  1-02 
http ://w w w.dtic . mil/doctrine/j el/doddict)  See  also  National  Security  Systems. 
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